diff --git a/docs/rpc-reference/wallet.md b/docs/rpc-reference/wallet.md index d97607d3af..623dff7c38 100644 --- a/docs/rpc-reference/wallet.md +++ b/docs/rpc-reference/wallet.md @@ -2818,7 +2818,7 @@ Request Parameters: | batch_size | NUMBER | False | The number of coins to spend per bundle, [Default: `batch_size` obtainable from [get_auto_claim](#get_auto_claim)] | | fee | NUMBER | False | An optional blockchain fee, in mojos | -When examing the on-chain metadata for a transaction, a coin with `"type": 6` is a clawback coin to be received by this wallet, and a coin with `"type": 7` is a clawback coin sent from this wallet. +When examining the on-chain metadata for a transaction, a coin with `"type": 6` is a clawback coin to be received by this wallet, and a coin with `"type": 7` is a clawback coin sent from this wallet.
Example @@ -3220,7 +3220,7 @@ Response: ### `cat_get_asset_id` -Functionality: Retrieve a the asset ID from a CAT wallet +Functionality: Retrieve the asset ID from a CAT wallet Usage: chia rpc wallet [OPTIONS] cat_get_asset_id [REQUEST] diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-home.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-home.md new file mode 100644 index 0000000000..ab9c27d834 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-home.md @@ -0,0 +1,311 @@ +--- +title: 学院主页 +slug: /academy-home +--- + +import ChialispIntro from '@site/static/img/academy/Intro2Chialisp.png'; +import SmartCoins from '@site/static/img/academy/SmartCoins.png'; +import Signatures from '@site/static/img/academy/Signatures.png'; +import InnerPuzzles from '@site/static/img/academy/InnerPuzzles.png'; + +import Consensus from '@site/static/img/academy/consensus.png'; +import Timelords from '@site/static/img/academy/timelords.png'; +import BlockFormation from '@site/static/img/academy/forming-blocks.png'; +import CoinSetModel from '@site/static/img/academy/coin-set.png'; +import Security from '@site/static/img/academy/security.png'; + +import FarmingOverview from '@site/static/img/academy/farming-overview.png'; +import ChallengesPlotFilters from '@site/static/img/academy/challenges-plot-filters.png'; +import Pools from '@site/static/img/academy/pools.png'; +import CreatingYourFirstPlot from '@site/static/img/academy/Intro2Farming.png'; + +import PrimitivesOverview from '@site/static/img/academy/primitives.png'; +import NFTs from '@site/static/img/academy/nft.png'; +import CATs from '@site/static/img/academy/cat.png'; +import DIDs from '@site/static/img/academy/did.png'; + +欢迎来到Chia学院，这里是深入研究Chia区块链技术的学术中心。 在这个以快速数字化转型为特征的时代，本学院提供对Chia区块链的全面探索，剖析其技术细节、现实应用以及其安全数据处理的细微差别。 作为Chia学院的学生，将深入了解Chia区块链的核心概念和功能。 + +## 课程 + +以下是几门精选课程，涵盖从区块链技术基础到Chialisp和实现的具体内容。 课程可以按任意顺序学习，因此请随意探索。 + +--- + +#### Chialisp概述 + +
+ + +
+
+
+ Intro to Chialisp +
+
+ + + +
+
+
+ + +
+
+
+ Smart Coins +
+
+ + + +
+
+
+ + +
+
+
+ Signatures +
+
+ + + +
+
+
+ + +
+
+
+ Inner Puzzles +
+
+ + + +
+
+
+ + +
+ +--- + +#### 区块链基础 + +
+ + +
+
+
+ Consensus +
+
+ + + +
+
+
+ + +
+
+
+ Timelords +
+
+ + + +
+
+
+ + +
+
+
+ Block Formation +
+
+ + + +
+
+
+ + +
+
+
+ Coin-Set Model +
+
+ + + +
+
+
+ + +
+
+
+ Security +
+
+ + + +
+
+
+ + +
+ +--- + +#### 绘图与耕种 + +
+ + +
+
+
+ Farming Overview +
+
+ + + +
+
+
+ + +
+
+
+ Challenges & Plot Filters +
+
+ + + +
+
+
+ + +
+
+
+ Pools +
+
+ + + +
+
+
+ + +
+
+
+ Creating Your First Plot +
+
+ + + +
+
+
+ + +
+ +--- + +#### Primitives + +
+ + +
+
+
+ Primitives Overview +
+
+ + + +
+
+
+ + +
+
+
+ NFTs +
+
+ + + +
+
+
+ + +
+
+
+ DIDs +
+
+ + + +
+
+
+ + +
+
+
+ CATs +
+
+ + + +
+
+
+ + +
+ +--- + +## 课程运作方式 + +查看[学院概述](https://docs.chia.net/academy-overview)页面，了解课程的呈现和组织方式。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-overview.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-overview.md index 03ae4ebb0c..e8a8ff4060 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-overview.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-overview.md @@ -1,89 +1,89 @@ --- -title: Academy Overview +title: 学院概述 slug: /academy-overview --- import Runnable from '@site/src/components/Runnable.tsx'; -The lesson pages in Chia Academy are thoughtfully designed to enhance the learning experience for students. Each lesson is organized in a user-friendly and visually appealing manner. The structure typically includes: +Chia学院的课程页面经过精心设计，以增强学生的学习体验。 每节课都以用户友好且视觉吸引的方式组织。 结构通常包括： --- -## Lesson title +## 课程标题 -Each lesson starts with a clear and descriptive title that informs students about the topic they are about to explore. +每节课以一个清晰且描述性的标题开始，告知学生他们将要探讨的主题。 --- -## Learning objectives +## 学习目标 -A set of specific learning objectives is provided at the beginning of the lesson. These objectives outline what students will be able to understand or do by the end of the lesson, setting clear expectations. +在课程开始时会提供一组具体的学习目标。 这些目标概述了学生在课程结束时能够理解或完成的内容，设定了明确的期望。 -- Learning Objective 1 -- Learning Objective 2 -- Learning Objective 3 +- 学习目标1 +- 学习目标2 +- 学习目标3 --- -## Content +## 内容 -The core content in each lesson is conveyed through structured, short format videos followed by scripts. This hybrid visual and text approach ensures accessibility and caters to diverse learning preferences. +每节课的核心内容通过结构化的短视频和脚本传达。 这种视觉和文本混合的方法确保了可访问性，适应了不同的学习偏好。 --- -## Script +## 脚本 -Each of the short format videos will be proceeded by the script used for creating the video. This written format ensures ease of translation catering to diverse learners. +每个短视频之后都会附有用于制作视频的脚本。 书面格式确保了翻译的便利性，适应了不同的学习者。
- Expand for the full script + 展开查看完整脚本 00:00 -This is an example of how the scripts will be provided including timestamps. +这是脚本提供的示例，包括时间戳。 00:20 -The timestamps are provided in set intervals and are formatted as `minutes:seconds` (`MM:SS`). +时间戳以设定的间隔提供，格式为`分钟:秒`（`MM:SS`）。
--- -## Common gotchas +## 常见问题 -While lessons are thoughtfully designed to facilitate learning, there are some common pitfalls or challenges that a learner might face. These will be described after the script for each lesson. +虽然课程经过精心设计以促进学习，但学习者可能会遇到一些常见的陷阱或挑战。 课程的这一部分会指出这些潜在的问题，并提供建议或解决方案。 -- **Gotcha 1:** Description of gotcha 1. -- **Gotcha 2:** Description of gotcha 2. -- **Gotcha 3:** Description of gotcha 3. +- **常见问题1:** 常见问题1的描述。 +- **常见问题2:** 常见问题2的描述。 +- **常见问题3:** 常见问题3的描述。 --- -## Knowledge check +## 知识检测 -Each lesson contains a brief self-assessment quiz designed to gauge learners' comprehension and retention of the video material. These assessments reinforce key concepts and help learners self-assess their understanding. +每节课程都包含一个简短的自我评估测验，旨在衡量学习者对视频材料的理解和记忆。 这些评估强化了关键概念，并帮助学习者自我评估他们的理解。 -The quiz section has two components, questions and answers. The questions contain lesson-applicable questions and the answers contain the corresponding answers. +测验部分有两个组成部分，问题和答案。 问题包含与课程相关的问题，答案包含相应的答案。 -Since this is a self assessment, you can of course skip the questions and go straight to the answers; but, we strongly recommend that you take the time to solve the question on your own before checking the answer. +由于这是一个自我评估，您当然可以跳过问题直接查看答案；但是，我们强烈建议您在查看答案之前花时间自己解决问题。 -:::tip Question 1 +:::tip 问题1 -What format is used for timestamps in the content scripts? +内容脚本中使用什么格式来表示时间戳？ :::
- Answer (expand when ready to see the answer) + 答案(当准备好查看答案时展开) -`MM:SS` or `minutes:seconds` +`MM:SS` 或者 `minutes:seconds`
-:::tip Question 2 +:::tip 问题2 -What is the serialized form of this Chialisp puzzle? +这个Chialisp谜题的序列化形式是什么？ ```chialisp (mod (arg1 arg2) (+ arg1 arg2)) @@ -93,7 +93,7 @@ What is the serialized form of this Chialisp puzzle?
- Answer (expand when ready to see the answer) + 答案(当准备好查看答案时展开) ```chialisp (+ 2 5) @@ -101,15 +101,15 @@ What is the serialized form of this Chialisp puzzle?
-:::tip Question 3 +:::tip 问题3 -What is the Chialisp puzzle for squaring a passed argument? +求传入参数的平方的Chialisp谜题是什么？ :::
- Answer (expand when ready to see the answer) + 答案(当准备好查看答案时展开) ```chialisp (mod (arg) @@ -124,35 +124,31 @@ What is the Chialisp puzzle for squaring a passed argument? --- -## Additional resources +## 附加资源 -Links to additional reading materials, videos, or external resources may be provided for learners who wish to delve deeper into the lessons subject. +为了帮助希望深入学习课程主题的学习者，可能会提供额外的阅读材料、视频或外部资源链接。 -### Runnable Chialisp and clvm plugins +### 可运行的Chialisp和clvm插件 -Runnable plugins are for Chialisp and clvm are provided with all applicable lessons. Take some time to familiarize yourself with the tools and learn how to best make use of them throughout the lessons. -Each plugin has a series of components: +所有适用的课程都提供了Chialisp和clvm的可运行插件。 花些时间熟悉这些工具，并学习如何在整个课程中最好地利用它们。 每个插件都有一系列组件： -**Language:** The language of the plugin (Chialisp or clvm) is in the top right corner. -**Solution:** The top section is the input or solution. -**Puzzle:** The bottom section is the puzzle. -**Run:** Each plugin has a play/run button to the right of the language identifier. -**Result:** After clicking run, the result of the puzzle appears below the puzzle. -**Cost:** After clicking run, the clvm cost of the puzzle is calculated and appears in the bottom right corner. -**Errors:** After clicking run, the plugin checks for and provides any errors in place of the result section. +**语言：** 插件的语言（Chialisp或clvm）位于右上角。 +**解决方案(Solution)：** 顶部部分是输入或解决方案。 +**谜题(Puzzle)：** 底部部分是谜题。 +**运行：** 每个插件在语言标识符右侧都有一个播放/运行按钮。 +**结果：** 单击运行后，谜题的结果将出现在谜题下方。 :::info -The plugins only validate the formatting and completeness of the code; they do not check for any potential exploits. +插件仅验证代码的格式和完整性；它们不检查任何潜在的漏洞。 ::: -#### Chialisp plugin +#### Chialisp 插件 -When clicking run, the puzzle will first be serialized into clvm (similar to the `run` command) then the solution will be passed into the serialized puzzle (similar to the `brun` command). -The below example is a Chialisp puzzle that squares the number passed as an argument. +单击运行时，谜题将首先被序列化为clvm（类似于 `run` 命令），然后解决方案将被传递到序列化谜题中（类似于 `brun` 命令）。 下面的示例是一个Chialisp谜题，它将传入的参数作为一个数字并返回其平方。 -Note the number `(5)` is used in the solution top section and the Chialisp formatted puzzle is entered in the puzzle bottom section. Clicking run on this puzzle will return `25` as the result. +注意解决方案顶部部分使用了数字 `(5)`，而 Chialisp 格式化的谜题被输入到谜题底部部分。 单击此谜题上的运行按钮将返回 `25` 作为结果。 @@ -167,12 +163,11 @@ Note the number `(5)` is used in the solution top section and the Chialisp forma -#### Clvm plugin +#### Clvm插件 -When clicking run, the solution will be passed into the serialized puzzle (similar to the `brun` command). -The below example uses the serialized puzzle from above that squares the number passed as an argument. +单击运行时，解决方案将被传递到序列化的谜题中（类似于`brun` 命令）。 下面的示例使用了上面序列化的谜题，将传入的参数作为一个数字并返回其平方。 -Note the number `(5)` is used in the solution top section and the serialized puzzle is entered in the puzzle bottom section. Clicking run on this puzzle will return `25` as the result. +注意解决方案顶部部分使用了数字 `(5)`，而序列化的谜题被输入到谜题底部部分。 单击此谜题上的运行按钮将返回 `25` 作为结果。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/block-formation-basics.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/block-formation-basics.md index c659de8e9f..ffc6105c82 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/block-formation-basics.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/block-formation-basics.md @@ -5,7 +5,7 @@ slug: /block-formation-basics In this lesson, we review the basics of block formation including the farmers role in validating transactions, forming blocks, and managing the mempool. -## Learning objectives +## 学习目标 - **Transaction Validation**: Learn how nodes validate transactions for inclusion in a block. - **Block Formation**: Understand farmers role in forming blocks. @@ -13,7 +13,7 @@ In this lesson, we review the basics of block formation including the farmers ro --- -## Content +## 内容
@@ -21,7 +21,7 @@ In this lesson, we review the basics of block formation including the farmers ro --- -## Script +## 脚本
@@ -45,7 +45,7 @@ and the relevant transactions are cleared from the mempool. In this way, transac --- -## Common gotchas +## 常见问题 - **Transaction Validation:** Transactions are validated by all nodes not only while blocks are being formed but also when the newly infused blocks are sent from peers, this eliminates a malicious actors ability from altering transactions even if they have the fastest timelord and have farmed the block. - **Block Formation vs Infusion:** Block formation is the process of combining proofs of space with transactions (the foliage) and is performed by the farmer while block infusion is the process of adding blocks to the chain itself and is performed by timelords. @@ -53,7 +53,7 @@ and the relevant transactions are cleared from the mempool. In this way, transac --- -## Knowledge check +## 知识检测 :::tip Question 1 - Transaction Validation @@ -94,10 +94,10 @@ False, it is timelords that **infuse** blocks to the chain and the role of full What is the Mempool? -A. Temporary storage on the network where transactions are queued before being confirmed. -B. The amount of system memory the blockchain can access. -C. The total size of all current plots on the network. -D. Another name for the chia blockchain database. +A. Temporary storage on the network where transactions are queued before being confirmed.\ +The amount of system memory the blockchain can access.\ +The total size of all current plots on the network.\ +Another name for the chia blockchain database. ::: @@ -111,9 +111,9 @@ A. Temporary storage on the network where transactions are queued before being c --- -## Additional resources +## 附加资源 -### Links +### 链接 - Transaction validation [overview](https://docs.chia.net/block-validation/#body-validation): dives into the requirements for validating the blocks body (which contains the transactions). - Block formation [overview](https://docs.chia.net/consensus-foliage): explores the intricacies of the full nodes role in block formation and when transaction blocks are formed. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/coinset-basics.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/coinset-basics.md index b147a35d00..d2fd74fc13 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/coinset-basics.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/coinset-basics.md @@ -5,7 +5,7 @@ slug: /coinset-basics In this lesson, we dive into the coinset model basics and learn what it means to spend a coin in Chia. -## Learning objectives +## 学习目标 - **Coin Contents**: Learn what data is stored in a coin. - **Coin Puzzle**: Understand the role of a coins puzzle. @@ -13,7 +13,7 @@ In this lesson, we dive into the coinset model basics and learn what it means to --- -## Content +## 内容
@@ -21,7 +21,7 @@ In this lesson, we dive into the coinset model basics and learn what it means to --- -## Script +## 脚本
@@ -72,7 +72,7 @@ the hash of the puzzle that contains the conditions, and the value of the coin. --- -## Common gotchas +## 常见问题 - **Coinset vs Account:** Chia adopts the coinset model where everything is a coin that has its own set of rules, more information about the coinset model can be found [here](https://docs.chia.net/coin-set-vs-account/). This differs from the account model which instead uses contracts (or accounts) to represent users balances and these balances are what is stored on the chain (as opposed to coins and those coins values). - **Puzzles:** All requirements for spending a coin are contained in the coins puzzle. These puzzles can be simple or complex and effect how, when, and by whom the coin can be spent. The coins puzzle must be determined at the coins creation and cannot be altered thereafter. @@ -80,7 +80,7 @@ the hash of the puzzle that contains the conditions, and the value of the coin. --- -## Knowledge check +## 知识检测 :::tip Question 1 - Coinset @@ -147,9 +147,9 @@ The coinset model. --- -## Additional resources +## 附加资源 -### Links +### 链接 - Detailed [coinset and account model comparisons](https://docs.chia.net/coin-set-vs-account/): details the differences between the coinset and account models including how these differences effect transactions. - Overview of [coin puzzles](https://docs.chia.net/coin-set-intro/#puzzles): overviews the role of a coins puzzle and the effect it has on the coins abiltiy to be spent. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/consensus-basics.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/consensus-basics.md index 5eb3f3aff1..289de75623 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/consensus-basics.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/consensus-basics.md @@ -5,7 +5,7 @@ slug: /consensus-basics In this lesson, we review the basics of consensus, the process by which to determine the true state of a blockchain. -## Learning objectives +## 学习目标 - **Farmers**: Understand the basic role of farmers in providing proofs of space. - **Timelords**: Understand the basic role of timelords in providing proofs of time. @@ -13,7 +13,7 @@ In this lesson, we review the basics of consensus, the process by which to deter --- -## Content +## 内容
@@ -21,7 +21,7 @@ In this lesson, we review the basics of consensus, the process by which to deter --- -## Script +## 脚本
@@ -52,7 +52,7 @@ This consensus method maintains trustless security through high-decentralization --- -## Common gotchas +## 常见问题 - **Proof of Space:** Chia relies on Proof of Space where the user stores deterministic x value tables in "plots" not to be confused with Proof of Capacity (PoC) where users store data of other network participants (like filecoin). - **Timelords:** Timelords play the role of issuing challenges, verifying proofs of space, and infusing blocks to the chain. Farmers submit their Proofs of Space to Timelords but it is the Timelords that infuse blocks. @@ -60,7 +60,7 @@ This consensus method maintains trustless security through high-decentralization --- -## Knowledge check +## 知识检测 :::tip Question 1 - Consensus Method @@ -130,9 +130,9 @@ What is the current (as of December 2023) ratio of plots that contain eligible p --- -## Additional resources +## 附加资源 -### Links +### 链接 - Consensus [detailed documentation](https://docs.chia.net/consensus-intro): details the Chia consensus including proofs of space and time, timelords, vdfs, and more. - Farming [basics](https://docs.chia.net/farming-basics): overviews the farming process and how to get started. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/security-basics.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/security-basics.md index ee6b3653b1..5d2ffc7bdd 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/security-basics.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/security-basics.md @@ -5,7 +5,7 @@ slug: /security-basics In this lesson, we learn the basic security implementations in Chia and how they protect users from bad actors. -## Learning objectives +## 学习目标 - **Decentralization**: Understand how a decentralized network enhances security and reduces attack options for bad actors. - **Coin Signatures**: Learn how coin signatures protect the users ability to spend the coins. @@ -13,7 +13,7 @@ In this lesson, we learn the basic security implementations in Chia and how they --- -## Content +## 内容
@@ -21,7 +21,7 @@ In this lesson, we learn the basic security implementations in Chia and how they --- -## Script +## 脚本
@@ -57,7 +57,7 @@ so you can be sure about what exactly a coin is going to do when it is spent. --- -## Common gotchas +## 常见问题 - **Decentralization:** The true decentralization of Chia greatly increases the economic costs associated with performing various attacks on Chia, protecting it from all scales of bad actors. - **Coin Signatures:** Ensuring that a coins solution requires signing ensures that only the intended user can spend the coin, this is an essential part of securing coins on Chia. @@ -65,7 +65,7 @@ so you can be sure about what exactly a coin is going to do when it is spent. --- -## Knowledge check +## 知识检测 :::tip Question 1 - Decentralization @@ -112,9 +112,9 @@ False, a custom-developed flavor of Lisp called Chialisp was developed to be use --- -## Additional resources +## 附加资源 -### Links +### 链接 - General [Security Overview](https://docs.chia.net/coin-set-security): overviews of Chia security and a review of potential attacks. - Overview of [Coin Signing](https://docs.chia.net/coin-set-security/#signing): reviews the purpose of signing and when it should be used for coins. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/timelord-basics.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/timelord-basics.md index be69213de2..354a62a205 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/timelord-basics.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/blockchain-basics/timelord-basics.md @@ -5,7 +5,7 @@ slug: /timelord-basics In this lesson, we dive into the role that Timelords play in the consensus by using VDFs to generate challenges. -## Learning objectives +## 学习目标 - **Proofs of Time**: Learn how Proofs of Time are created by timelords and what role they perform. - **Verifiable Delay Function (VDF)**: Understand the basics of VDFs. @@ -13,7 +13,7 @@ In this lesson, we dive into the role that Timelords play in the consensus by us --- -## Content +## 内容
@@ -21,7 +21,7 @@ In this lesson, we dive into the role that Timelords play in the consensus by us --- -## Script +## 脚本
@@ -53,7 +53,7 @@ While at least one Timelord is required for the blockchain to function, anyone c --- -## Common gotchas +## 常见问题 - **VDFs and Proofs of Time:** A Verifiable Delay Function, also referred to as a Proof of Time or VDF, is a proof that a sequential function was executed a certain number of times. - **Timelords:** Only 1 timelord is needed to keep the chain moving but anyone can run a timelord and multiple timelords on the network ensures resiliency. Some attacks that timelords protect against are documented [here](https://docs.chia.net/consensus-attacks#faster-timelord). @@ -61,15 +61,15 @@ While at least one Timelord is required for the blockchain to function, anyone c --- -## Knowledge check +## 知识检测 :::tip Question 1 - Timelords How many Farmers need to run a Timelord for the network? -A. Every Farmer needs to run a Timelord. -B. At least half the Farmers need to run a Timelord. -C. Farmers aren't able to run Timelords. +A. Every Farmer needs to run a Timelord.\ +At least half the Farmers need to run a Timelord.\ +Farmers aren't able to run Timelords.\ D. Just one Timelord is needed for the network. ::: @@ -105,10 +105,10 @@ A. Timelords What are the primary purposes of VDFs? (choose all that apply) -A. To slow down the network. -B. To prove time has passed between blocks. -C. Provide security to the network. -D. Prepare for time travel integrations. +A. To slow down the network.\ +B. To prove time has passed between blocks.\ +Provide security to the network.\ +Prepare for time travel integrations. ::: @@ -116,8 +116,8 @@ D. Prepare for time travel integrations. Answer (expand when ready to see the answer) -B. To prove time has passed between blocks. -C. Provide security to the network. +B. To prove time has passed between blocks.\ +Provide security to the network.
@@ -139,9 +139,9 @@ True --- -## Additional resources +## 附加资源 -### Links +### 链接 - Timelords [detailed documentation](https://docs.chia.net/timelord-algorithm/): details the timelords role in the consensus model. - Proofs of Time / VDFs [overview](https://docs.chia.net/proof-of-time/): detailed overview for Proofs of Time and VDFs. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-inner-puzzle.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-inner-puzzle.md index cdb027cae6..fcb26aec47 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-inner-puzzle.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-inner-puzzle.md @@ -5,16 +5,16 @@ slug: /chialisp-inner-puzzle import Runnable from '@site/src/components/Runnable.tsx'; -In this lesson, we'll talk about why you might want to nest puzzles and how to set them up. +在这节课上，我们将讨论为什么您可能希望嵌套谜题以及如何设置它们。 -## Learning objectives +## 学习目标 -- **Functions**: Learn how to define and execute functions in Chialisp. -- **Nesting Puzzles**: Understand the use of nesting puzzles in Chialisp. +- **函数（Functions）**：学习如何在 Chialisp 中定义和执行函数。 +- **嵌套谜题（Nesting Puzzles）**：了解在 Chialisp 中使用嵌套谜题的用途。 --- -## Content +## 内容
@@ -22,72 +22,72 @@ In this lesson, we'll talk about why you might want to nest puzzles and how to s --- -## Script +## 脚本
Expand for the full script 00:00\ -All puzzles result in the output of a condition that tells a blockchain what to do with a coin that it's wrapped in. Inner puzzles can be thought of as a coin within a coin where the result is a condition that is passed to the outer puzzle which executes it. +所有的谜题都会产生一个条件输出，告诉区块链在其中包装的硬币该做什么。 内部谜题可以看作是硬币中的硬币，结果是一个传递给外部谜题并由其执行的条件。 00:20\ -One specific use for this functionality is if you wanted to use a generic inner puzzle and wrap it in an outer puzzle that verifies a signature. The outer puzzle can be a sort of template that you can pass in any generic inner puzzle and it will be signature protected by the outer puzzle. Let's create this exact outer puzzle template. +这种功能的一个特定用途是，如果你想使用一个通用的内部谜题，并将其包装在一个验证签名的外部谜题中。 外部谜题可以看作是一种模板，你可以将任何通用的内部谜题传递进去，它将由外部谜题保护。 让我们创建这个外部谜题模板。 00:40\ -We're going to define a module, and for our parameters we'll have a `PUBLIC_KEY` that we'll curry in later, an `INNER_PUZZLE` that we'll also curry in, and then the `inner_solution`. We'll include the `condition_codes.clib` library file and the `sha256tree.clib` library file as well. Then, we're going to define a new function. +我们要定义一个模块，对于我们的参数，我们将有一个稍后传入的 `PUBLIC_KEY`，一个我们也将传入的 `INNER_PUZZLE`，然后是 `inner_solution`。 我们还将包含 `condition_codes.clib` 和 `sha256tree.clib` 库文件。 然后，我们将定义一个新的函数。 01:00\ -We'll call this `calculate_output` and in the parameters we'll have our `PUBLIC_KEY`, the `inner_solution`, and the `conditions` that we'll execute. In a combine statement, we'll have the standard signature verification that we used in the previous video. (`(defun calculate_output (PUBLIC_KEY inner_solution conditions) (c (list AGG_SIG_MET PUBLIC_KEY (sha256tree inner_solution)) conditions))`) +我们将其命名为 `calculate_output`，在参数中我们将有我们的 `PUBLIC_KEY`，`inner_solution`，以及我们将执行的 `conditions`。 在一个组合语句中，我们将使用之前视频中使用的标准签名验证。 (`(defun calculate_output (PUBLIC_KEY inner_solution conditions) (c (list AGG_SIG_MET PUBLIC_KEY (sha256tree inner_solution)) conditions))`) 01:20\ -For the message that we're verifying, we'll be verifying the `inner_solution` and then we'll return the `conditions`. Now that we've defined our new function, we'll call it with `calculate_output`, provide the `PUBLIC_KEY` and the `inner_solution`, and then we'll use the `apply` operator or `a` on our `INNER_PUZZLE`, providing the `inner_solution`. (`calculate_output PUBLIC_KEY inner_solution (a INNER_PUZZLE inner_solution)`) +对于我们要验证的消息，我们将验证 `inner_solution`，然后返回 `conditions`。 现在我们已经定义了我们的新函数，我们将使用 `calculate_output` 调用它，提供 `PUBLIC_KEY` 和 `inner_solution`，然后我们将对我们的 `INNER_PUZZLE` 使用 `apply` 运算符或 `a`，提供 `inner_solution`。 (`calculate_output PUBLIC_KEY inner_solution (a INNER_PUZZLE inner_solution)`) 01:40\ -The `apply` operator is how you execute some code. So the `INNER_PUZZLE` will be executed with the `inner_solution`. So this puzzle will first evaluate the inner puzzle with the `(a INNER_PUZZLE inner_solution))` method, and use the result as the condition for our `calculate_output` function. +`apply` 运算符是执行一些代码的方式。 因此，`INNER_PUZZLE` 将使用 `inner_solution` 执行。 因此，这个谜题将首先使用 `(a INNER_PUZZLE inner_solution))` 方法评估内部谜题，并将其结果用作我们的 `calculate_output` 函数的条件。 02:00\ -This function requires a signature of the `inner_solution` to pass. Now let's write the inner puzzle. For this puzzle, we're going to use a condition called `ASSERT_HEIGHT_RELATIVE`, which specifies when a coin can be spent, based on the number of blocks passed since coin creation. We'll define a module and in our parameters, we'll curry in the `REQUIRED_BLOCKS`. This will be a number of blocks that have to pass before the coin can be spent. +这个函数需要 `inner_solution` 的签名才能通过。 现在让我们编写内部谜题。 对于这个谜题，我们将使用一个称为 `ASSERT_HEIGHT_RELATIVE` 的条件，它指定了基于自硬币创建以来经过的块数的硬币何时可以被花费。 我们将定义一个模块，在我们的参数中，我们将传入 `REQUIRED_BLOCKS`。 这是一个必须经过的块数，硬币才能被花费。 02:20\ -Then, we'll have our `conditions`. We'll include the `condition_codes.clib` library again, and then we'll define a statement that uses the `ASSERT_HEIGHT_RELATIVE` condition on the `REQUIRED_BLOCKS` that we curried in, and then we'll return the `conditions`. +然后，我们将有我们的 `conditions`。 我们再次包含 `condition_codes.clib` 库文件，然后我们将定义一个语句，该语句使用我们传入的 `REQUIRED_BLOCKS` 上的 `ASSERT_HEIGHT_RELATIVE` 条件，然后我们将返回 `conditions`。 02:40\ -All right, now we have both our inner puzzle and our outer puzzle. Let's curry in the needed values. First we'll get our public key with `chia keys show`, and then we'll curry the block value into the inner puzzle with `cdv clsp curry inner-puzzle.clsp -a` and specify the number of blocks that we want to pass. +好了，现在我们有了内部谜题和外部谜题。 让我们传入所需的值。 首先，我们使用 `chia keys show` 获取我们的公钥，然后我们将块值传入内部谜题，使用 `cdv clsp curry inner-puzzle.clsp -a` 并指定我们想要经过的块数。 03:00\ -In this case, we'll use `20`. We can now curry this result, along with our public key, into the outer puzzle with `cdv clsp curry outer-puzzle.clsp -a`, enter our public key, `-a` and in quotes we'll paste the compiled inner puzzle. +在这种情况下，我们将使用 `20`。 现在我们可以将此结果与我们的公钥一起传入外部谜题，使用 `cdv clsp curry outer-puzzle.clsp -a`，输入我们的公钥，`-a`，然后在引号中粘贴编译后的内部谜题。 03:20\ -Now that we have our final compiled puzzle, we can go ahead and create a coin using the process that we covered in the last video. Once the coin has been created, we can create our solution for this coin. First we get our wallet address and `decode` it. We'll use this in our desired solution. Again, we'll be using the `CREATE_COIN` condition signified by the code `51`. +现在我们有了最终的编译谜题，我们可以继续创建一个硬币，使用我们在上一个视频中介绍的流程。 一旦硬币被创建，我们就可以为这个硬币创建解决方案。 首先我们获取我们的钱包地址并进行 `decode`。 我们将在我们想要的解决方案中使用这个地址。 同样，我们将使用代码 `51` 表示的 `CREATE_COIN` 条件。 03:40\ -Note that I'm nesting the solution in four (4) sets of parentheses. This is because the outer puzzle parameters list is passed in wrapped with parentheses as is the inner solution. In the inner puzzle, we have another set of parentheses for the list of conditions, and each condition is also wrapped. +注意，我将解决方案嵌套在了4组括号中。 这是因为外部谜题参数列表被包裹在括号中，内部解决方案也是如此。 在内部谜题中，我们有另一组括号用于条件列表，并且每个条件也被包裹在其中。 04:00\ -It's important to understand the structure of the puzzle to make sure that the solution you provide is structured properly. Now we'll add the encoded solution into our spend bundle where we already have the coin info and puzzle reveal from coin creation. Next, we'll get our signature using the method we outlined in the previous video. We'll hash our solution and concatenate it with the coin ID and genesis challenge. +了解谜题的结构非常重要，以确保您提供的解决方案结构正确。 现在我们将编码的解决方案添加到我们的花费包中，其中已经包含了来自硬币创建的硬币信息和谜题展示。 接下来，我们将使用我们在上一个视频中概述的方法获取我们的签名。 我们将解决方案进行哈希处理，然后将其与硬币 ID 和起源挑战进行连接。 04:20\ -Now we can sign the resulting message with `chia keys sign` and copy the signature into our spend bundle, being sure to append `0x` to signify that it's a value. Now run `cdv rpc pushtx spendbundle.json`. +现在我们可以使用 `chia keys sign` 对结果消息进行签名，并将签名复制到我们的花费包中，确保附加 `0x` 以表示它是一个值。 现在运行 `cdv rpc pushtx spendbundle.json`。 04:40\ -If the number of blocks is not yet passed, it will have a pending status. If successful, we can look up the coin record again and see that the spent block index is more than 20 blocks later than the confirmed block index. In this video, we learned how inner puzzles work and how they interact with outer puzzles. Thanks so much for watching, catch you next time. +如果块数尚未经过，它将显示为挂起状态。 如果成功，我们可以再次查找硬币记录，并查看已花费的块索引比确认的块索引晚了 20 个块。 在这个视频中，我们学习了内部谜题的工作原理以及它们与外部谜题的交互。 非常感谢观看，下次再见。
--- -## Common gotchas +## 常见问题 -- **More Parentheses:** It's important to take note of where your solutions are going to be used in your puzzle and wrap them in the appropriate amount of parentheses. This can be counter-intuitive as the parentheses can seem unecessary at first glance. +- **更多的括号**：重要的是要注意你的解决方案将在谜题中的哪里使用，并用适当数量的括号将它们包裹起来。 这可能有些反直觉，因为乍一看，括号似乎是不必要的。 --- -## Knowledge check +## 知识检测 -:::tip Question 1 - Evaluating Inner Puzzles +:::tip 问题1 - 评估内部谜题 -What operator is used to evaluate a puzzle within another puzzle? +什么运算符用于评估另一个谜题中的谜题？ ::: @@ -95,7 +95,7 @@ What operator is used to evaluate a puzzle within another puzzle? Answer (expand when ready to see the answer) -The `apply` operator. (`a`) +`apply`运算符。 (`a`) ```chialisp (a INNER_PUZZLE inner_solution) @@ -103,9 +103,9 @@ The `apply` operator. (`a`)
-:::tip Question 2 - A New Condition +:::tip 问题2 - 一个新条件 -What does the `ASSERT_HEIGHT_RELATIVE` condition check for? +`ASSERT_HEIGHT_RELATIVE` 条件检查什么？ ::: @@ -113,19 +113,19 @@ What does the `ASSERT_HEIGHT_RELATIVE` condition check for? Answer (expand when ready to see the answer) -`ASSERT_HEIGHT_RELATIVE` checks for how many blocks have passed since coin creation. It allows the resolution of a puzzle after a predefined number of blocks have passed. +`ASSERT_HEIGHT_RELATIVE` 检查自货币创建以来经过了多少个区块。 它允许在预定义数量的区块经过后解决谜题。
--- -## Additional resources +## 附加资源 -### Runnable Chialisp and clvm plugins +### 可运行的Chialisp和clvm插件 -For information on using these plugins please refer to the [academy overview](/academy-overview#runnable-chialisp-and-clvm-plugins) +有关使用这些插件的信息，请参阅[学院概述](/academy-overview#可运行的chialisp和clvm插件)。 -#### Chialisp plugin +#### Chialisp 插件 @@ -137,7 +137,7 @@ For information on using these plugins please refer to the [academy overview](/a -#### Clvm plugin +#### Clvm插件 @@ -147,11 +147,11 @@ For information on using these plugins please refer to the [academy overview](/a -### Links +### 链接 -- General [chialisp concepts](https://docs.chia.net/guides/chialisp-concepts): overviews of currying, inner puzzles, and morphing conditions. -- Guided [chialisp walkthroughs](https://docs.chia.net/guides/): guides for installation, creating smart coins, and working with BLS signatures. -- Chialisp [detailed documentation](https://chialisp.com/): detailed information on all aspects of chialisp. +- [Chialisp基本概念](https://docs.chia.net/guides/chialisp-concepts)：包括柯里化（currying）、内部谜题（inner puzzles）和条件变换（morphing conditions）的概述。 +- 指导性的[Chialisp演练](https://docs.chia.net/guides/)：安装、创建智能币和使用BLS签名的指南。 +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-intro.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-intro.md index b45464d324..1aeacb7250 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-intro.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-intro.md @@ -5,17 +5,17 @@ slug: /chialisp-intro import Runnable from '@site/src/components/Runnable.tsx'; -In this lesson, we review the basics of Chialisp including syntax & structure, inequalities and if statements, and setting up a development environment. +在本课程中，我们将回顾 Chialisp 的基础知识，包括语法& 结构、不等式和 if 语句，以及设置开发环境。 -## Learning objectives +## 学习目标 -- **Syntax and Structure**: Understand the basic Chialisp syntax and structure. -- **Puzzles and Solutions**: Understand the use of puzzles and solutions in Chialisp. -- **Development Environment**: Setup and configure the Chialisp development environment. +- **语法和结构**：理解基本的 Chialisp 语法和结构。 +- **谜题和解决方案**：了解在 Chialisp 中使用谜题和解决方案。 +- **开发环境**：安装和配置 Chialisp 开发环境。 --- -## Content +## 内容
@@ -23,77 +23,77 @@ In this lesson, we review the basics of Chialisp including syntax & structure, i --- -## Script +## 脚本
- Expand for the full script + 展开查看完整脚本 00:00 -We're going to go over the very basics of Chialisp we'll talk about a few things the basic syntax and structure of a Chialisp program puzzles and solutions and set up a development environment to test it all out. +我们将简要介绍 Chialisp 的基础知识，包括：Chialisp 程序的基本语法和结构、谜题和解决方案，以及设置开发环境来测试这些内容。 00:20 -So let's get started, the first thing you'll want to do is make sure you have the correct version of python. If you type in python3-version make sure you have python 3.10. Next we're going to want to create a virtual environment so if you run the command python3 -m venv venv. +So let's get started, the first thing you'll want to do is make sure you have the correct version of python. If you type in python3-version make sure you have python 3.10. Next we're going to want to create a virtual environment so if you run the command python3 -m venv venv. 如果你输入 `python3 --version`，确保你安装的是 Python 3.10。 接下来，我们要创建一个虚拟环境，你可以运行命令 `python3 -m venv venv`。 00:40 -This is going to create a virtual environment that we can activate to do our development in and to activate it we're going to type in this command bin\activate and now you can see that we are in a virtual environment. +这将创建一个虚拟环境，我们可以激活它进行开发。要激活它，我们将输入以下命令：`bin\activate`，现在你可以看到我们已经进入了虚拟环境。 01:00 -Next we're going to want to install the Chia Dev tools and you can do this by in running pip install Chia Dev tools and let it do its thing. So now let's just make sure we have the correct version by typing cdv --version and you can see we have version 1.1.4. +接下来，我们需要安装 Chia 开发工具，你可以通过运行 `pip install Chia Dev tools` 来完成。 现在，让我们确保我们安装了正确版本，输入 `cdv --version`，你会看到我们的版本是 1.1.4。 01:20 -So now we have our development environment all set up let's go over some key lisp basics. This is the basic run command it takes a list with an operator followed by two operands. +现在我们已经设置好了开发环境，让我们来学习一些关键的 Lisp 基础知识。 这是基本的运行命令，它接受一个带有运算符后跟两个操作数的列表（list）。 01:40 -In this example, we have the operands two and three and they'll be added together so we should get five. That's not very useful though so let's create a program that we can pass in some parameters and do the addition for us. All right in this example we have defined a module that receives two parameters arg1 arg2 and then runs the operation on those two parameters so when we run this we're going to get the compiled version of the program that we just wrote. +在这个例子中，我们有两个操作数，分别是2和3，它们将被相加，所以我们应该得到5。 但这并不是很有用，所以让我们创建一个程序，可以传入一些参数，并为我们执行加法。 在这个例子中，我们定义了一个模块，接收两个参数 arg1 和 arg2，然后对这两个参数进行操作，所以当我们运行它时，我们将得到刚刚编写的程序的编译版本。 02:00 -This is called the puzzle the arguments will be passed into the puzzle as a solution. So how do we run this code? Well our second command is brun so if we pass this compiled puzzle through the brun command and give it a solution such as 7 and 10. +这被称为谜题（puzzle），参数将作为解决方案（solution）传递到谜题中。 那么我们如何运行这段代码呢？ 我们的第二个命令是 `brun`，所以如果我们通过 `brun` 命令传递这个编译后的谜题，并给它一个解决方案，比如 7 和 10。 02:20 -It's going to use that solution as the parameters for the program so we should get 17. Now let's talk about inequalities and if statements. In this program I'm comparing two numbers 10 and 5, and seeing if the first is greater than the second. So in this case the result would be true and we receive a 1. +它将使用该解决方案作为程序的参数，所以我们应该得到 17。 现在让我们谈谈不等式和 if 语句。 在这个程序中，我比较了两个数字 10 和 5，并检查第一个是否大于第二个。 因此在这种情况下，结果将为真，我们会收到一个 1。 02:40 -In the opposite case it would be false and we received an empty set so if statements are going to take this structure if followed by our comparison then the result if it's true followed by the result if it's false. So let's run this program, if 1 which is true return true, else return false. +在相反的情况下，结果将为假，并且我们会收到一个空集（empty set），so if statements are going to take this structure if followed by our comparison then the result if it's true followed by the result if it's false. 所以让我们运行这个程序，如果是1意味着结果为真，则返回true，否则返回false。 03:00 -So we expect to see true. So let's create a puzzle using comparisons and if statements. So we're going to type run and define a module that takes two arguments arg1 arg2. So we're going to define an if statement and we want to know if we add the two arguments together if they're greater than 100. +所以我们期望的结果是真（true）。 那么让我们使用比较和 if 语句创建一个谜题。 我们将输入 `run` 并定义一个接受两个参数 `arg1` 和 `arg2` 的模块（module ）。 我们将定义一个 if 语句，我们想知道如果我们将这两个参数加在一起，它们是否大于 100。 03:20 -So if greater than the addition of argument 1 and argument 2 is greater than 100 then we're going to return large if it's true and small if it's false. +所以如果大于参数 1 和参数 2 的加法结果大于 100，那么如果为真，我们将返回 "large"，如果为假，我们将返回 "small"。 03:40 -We'll close this and as you can see it's really easy to get lost in the parentheses so for future videos we'll be using a text editor which will make this a lot easier but if we run this we will receive the compiled version of our program and let's pass that puzzle into brun with our solution so run and +我们将关闭这个，正如你所看到的，很容易在括号中迷失方向，所以在未来的视频中，我们将使用文本编辑器，这将使得操作变得更加简单，但如果我们运行这个，我们将收到我们程序的编译版本，然后将这个谜题与我们的解决方案一起传递给 `brun`。 04:00 -we'll add 70 and 100 which is guaranteed to be over 100 so we should receive the result large and that's it. That's the basics of Chialisp; we've talked about basic operators, inequalities if statements compiling our program into puzzles, and passing in a solution. +我们将添加 70 和 100，这肯定会超过 100，所以我们应该收到结果 "large"，就是这样。 这就是 Chialisp 的基础知识；我们讨论了基本运算符、不等式、if 语句、将程序编译成谜题（puzzles），并传递解决方案（solution）。 04:20 -In future videos we'll talk about smart coins signatures and inner puzzles. Thanks for joining me and I'll catch you in the next video! +在未来的视频中，我们将讨论智能币、签名和内部谜题。 感谢您的参与，我们下个视频见！
--- -## Common gotchas +## 常见问题 -- **run vs brun:** Run is used to serialize and run chialisp puzzles while brun is used to run clvm serialized puzzles generally when passing arguments. -- **Parentheses:** Chialisp is part of the fully parenthesized prefix notation programming language family tracing their [origins]() to LISP 1 from the 1950s. One highly apparent aspect of these languages is their use of parenthesis to denote lists. It is recommended to use an IDE with proper syntax highlighting when writing these languages to ensure that all parenthesis are in the proper places. To help with this here is a [Chialisp language server extension](https://marketplace.visualstudio.com/items?itemName=ChiaNetwork.chialisp) for Visual Studio. -- **Prefix Notation:** Chialisp being part of the LISP family uses prefix notation. This means that the functions or operators appears first with their arguments following. +- **run vs brun:** `run` 用于序列化并运行 Chialisp 谜题，而 `brun` 用于运行 clvm 序列化的谜题，通常用于传递参数。 +- **括号（Parentheses）：**Chialisp 是完全括号前缀表示法编程语言家族的一部分，可以[追溯]()到上世纪 50 年代的 LISP 1。 这些语言的一个显而易见的特点是它们使用括号来表示列表（lists）。 建议在编写这些语言时使用具有适当语法高亮功能的集成开发环境，以确保所有括号都处于正确的位置。 为了帮助解决这个问题，这里有一个适用于 Visual Studio 的 [Chialisp 语言服务器扩展](https://marketplace.visualstudio.com/items?itemName=ChiaNetwork.chialisp)。 +- **前缀表示法：**Chialisp 作为 LISP 家族的一部分，使用前缀表示法。 这意味着函数或运算符首先出现，其参数紧随其后。 --- -## Knowledge check +## 知识检测 -:::tip Question 1 - Subtraction +:::tip 问题 1 - 减法 -What is a chialisp puzzle for subtracting two arguments? +请给出一个用于计算两个参数相减的Chialisp 谜题？ :::
- Answer (expand when ready to see the answer) + 答案(当准备好查看答案时展开) ```chialisp (mod (arg1 arg2) @@ -103,9 +103,9 @@ What is a chialisp puzzle for subtracting two arguments?
-:::tip Question 2 - Comparison +:::tip 问题 2 - 比较 -What is the serialized form of this chialisp puzzle? +这个 Chialisp 谜题的序列化形式是什么？ ```chialisp (mod (arg1 arg2) @@ -117,7 +117,7 @@ What is the serialized form of this chialisp puzzle?
- Answer (expand when ready to see the answer) + 答案(当准备好查看答案时展开) ```chialisp (> 2 5) @@ -125,17 +125,17 @@ What is the serialized form of this chialisp puzzle?
-:::tip Question 3 - If Statement +:::tip 问题 3 - If 语句 -What is the result of the below serialized puzzle and solution? +下面的序列化谜题和解决方案的结果是什么？ -Puzzle: +谜题： ```chialisp (a (i 2 (q 1 . "true") (q 1 . "false")) 1) ``` -Solution: +解决方案: ```chialisp (1) @@ -145,26 +145,26 @@ Solution:
- Answer (expand when ready to see the answer) + 答案(当准备好查看答案时展开) `"true"`
-:::tip Question 4 - Combining all of the above +问题 4 - 将上述所有内容结合起来 -What is a Chialisp puzzle that performs the following? +执行以下操作的 Chialisp 谜题是什么？ -- Accepts two arguments -- Adds the two arguments together -- Compares the sum of the arguments to 100 -- Results in "Large" when the sum is greater than 100 and "Small" when the sum is less than 100 +- 接受两个参数 +- 将这两个参数相加 +- 比较参数的和是否大于 100 +- 当参数的和大于 100 时结果为 "Large"，当参数的和小于 100 时结果为 "Small" :::
- Answer (expand when ready to see the answer) + 答案(当准备好查看答案时展开) ```chialisp (mod (arg1 arg2) @@ -176,13 +176,13 @@ What is a Chialisp puzzle that performs the following? --- -## Additional resources +## 附加资源 -### Runnable Chialisp and clvm plugins +### 可运行的Chialisp和clvm插件 -For information on using these plugins please refer to the [academy overview](/academy-overview#runnable-chialisp-and-clvm-plugins) +有关如何使用这些插件的信息，请参阅[学院概述](/academy-overview#可运行的chialisp和clvm插件) -#### Chialisp plugin +#### Chialisp 插件 @@ -194,7 +194,7 @@ For information on using these plugins please refer to the [academy overview](/a -#### Clvm plugin +#### Clvm插件 @@ -204,11 +204,11 @@ For information on using these plugins please refer to the [academy overview](/a -### Links +### 链接 -- General [chialisp concepts](https://docs.chia.net/guides/chialisp-concepts): overviews of currying, inner puzzles, and morphing conditions. -- Guided [chialisp walkthroughs](https://docs.chia.net/guides/): guides for installation, creating smart coins, and working with BLS signatures. -- Chialisp [detailed documentation](https://chialisp.com/): detailed information on all aspects of chialisp. -- Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. +- Chialisp[基本概念](https://chialisp.com/chialisp-concepts/)：包括柯里化（currying）、内部谜题（inner puzzles）和条件变换（morphing conditions）的概述。 +- 指导性的[Chialisp演练](https://docs.chia.net/guides/)：安装、创建智能币和使用BLS签名的指南。 +- Chialisp[详细文档](https://chialisp.com/)：关于Chialisp所有方面的详细信息 +- 从[Discord](https://discord.gg/chia)获取支持：如需进一步支持，请加入我们的Discord服务器，并在 #chialisp 或 #support 频道中提问 --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-signatures.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-signatures.md index 45807de540..2e2eeb55dd 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-signatures.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-signatures.md @@ -5,16 +5,16 @@ slug: /chialisp-signatures import Runnable from '@site/src/components/Runnable.tsx'; -In this lesson, we go over how to secure coins using signatures. +在这节课中，我们将讨论如何使用签名来保护币。 -## Learning objectives +## 学习目标 -- **Signing and Signatures**: Understand the uses and benefits of signatures. -- **Chialisp Library files**: Learn about helpful Chialisp libraries to simplify development. +- **签名（Signing、Signatures）**：了解签名的用途和好处。 +- **Chialisp 库文件**：了解简化开发的有用Chialisp库。 --- -## Content +## 内容
@@ -22,91 +22,91 @@ In this lesson, we go over how to secure coins using signatures. --- -## Script +## 脚本
Expand for the full script 00:00\ -We created our first smart coin and secured it so that only someone with the correct password could spend it. In this video, we'll use a signature to secure our coin so that only the person with the correct signature will be able to spend the coin. +我们创建了我们的第一个智能币，并将其安全地保护，只有拥有正确密码的人才能使用它。 在本视频中，我们将使用签名来保护我们的币，以便只有拥有正确签名的人才能使用这个币。 00:20\ -So what is a signature? A digital signature allows you to sign a message with a private key. This message can then be verified by a recipient using your public key. Let's start with an example of signing a message and then verifying it. +那么什么是签名？ 数字签名允许您使用私钥对消息进行签名。 然后，接收方可以使用您的公钥验证此消息。 让我们从签署消息并验证它的示例开始。 00:40\ -Run `chia keys sign --message` with the message `"hello" --hdpath m` then choose your wallet ID. This process will sign the message 'hello' with your private key. To verify this message we'll run `chia keys verify` enter the message, then the signature and the sender's public key. (`chia keys verify --message hello --signature [SIG] --public_key [PUB_KEY]`) +运行 `chia keys sign --message`，消息为 `"hello"`，`--hdpath m`，然后选择您的钱包ID。 此过程将使用您的私钥对消息 'hello' 进行签名。 要验证此消息，我们将运行 `chia keys verify`，输入消息，然后是签名和发送方的公钥。 (`chia keys verify --message hello --signature [SIG] --public_key [PUB_KEY]`) 01:00\ -So now that we know how signing works, let's create a coin that can be spent when given the correct signature. So in our chialisp file, let's define a module that takes two parameters. The first will be a public key that we'll curry in later. This will determine who is able to spend the coin. +现在我们知道签名的工作原理了，让我们创建一个只有在提供正确签名时才能花费的币。 因此，在我们的 chialisp 文件中，让我们定义一个接受两个参数的模块。 第一个将是我们稍后将添加的公钥。 这将确定谁可以花费这个币。 01:20\ -The second parameter will be the conditions that determine how the coin will be spent. Next, we'll include some libraries to make our code a bit easier to write. The first lets us use written condition codes rather than number codes, and the second is a library for tree hashing. +第二个参数将是决定如何花费币的条件。 接下来，我们将包含一些库，以使我们的代码更易于编写。 第一个库允许我们使用编写的条件代码而不是数字代码，第二个库是一个用于树哈希的库。 01:40\ -To install these libraries, run this command in the terminal. `cdv clsp retrieve sha256tree condition-codes`. Back to our chialisp file, we'll define a combine statement with`c` and for the first parameter, create a list composed of the `AGG_SIG_ME` condition, our public key parameter and the conditions parameter run through the tree hashing library. (`(c (list AGG_SIG_ME PUBLIC_KEY (sha256tree conditions)) conditions)`) +要安装这些库，在终端中运行此命令。 `cdv clsp retrieve sha256tree condition-codes`. 回到我们的 chialisp 文件，我们将使用 `c` 定义一个组合语句，对于第一个参数，创建一个由 `AGG_SIG_ME` 条件、我们的公钥参数和通过树哈希库的条件参数组成的列表。 (`(c (list AGG_SIG_ME PUBLIC_KEY (sha256tree conditions)) conditions)`) 02:00\ -The second parameter in the combine statement will be the conditions that are passed into the program. So what does this do? Well the `AGG_SIG_ME` condition is a standard condition that signs a message with a public key. In this case we are currying in the key and the message is the tree hash of the conditions parameter. +组合语句中的第二个参数将是传递到程序中的条件。 那么这是做什么的呢？ `AGG_SIG_ME` 条件是一个标准条件，用公钥签名消息。 在这种情况下，我们将在键和消息是条件参数的树哈希之后对键进行曲线处理。 02:20\ -We do this so that the conditions cannot be modified by the farmer. So in order to spend the coin, the user must provide a solution that contains a list of conditions; or how they'd like to spend the coin; as well as a signature to show that they are the ones authorized to do so. +我们这样做是为了防止农民修改条件。 因此，为了花费币，用户必须提供一个包含条件列表的解决方案；或者他们希望如何花费币的方式；以及一个签名，以表明他们是授权进行操作的人。 02:40\ -For this example, we're going to create a solution that uses the `CREATE_COIN` condition to essentially unlock the value of the coin and send it back to our wallet. First, let's finish creating this coin. We'll get our master public key with `chia keys show` and curry that into our program. It's important to prefix the key with `0x` to show that it is a value. +在本示例中，我们将创建一个解决方案，该解决方案使用 `CREATE_COIN` 条件来解锁币的价值，并将其发送回我们的钱包。 首先，让我们完成创建此币。 我们将使用 `chia keys show` 获取我们的主公钥，并将其曲线化到我们的程序中。 重要的是要用 `0x` 前缀表示它是一个值。 03:00\ -Now we'll get the puzzle reveal with `opc` and enter in the compiled code. Make sure to save this for later. And for the puzzle hash we'll run `opc -h` and enter the compiled code. We'll save this for later as well. We'll need to take the puzzle hash and encode it into an address. Run `cdv encode --prefix txch` and enter the puzzle hash. +现在我们将使用 `opc` 获取拼图展示，并输入编译代码。 记得保存这个以备将来使用。 对于拼图哈希，我们将运行 `opc -h` 并输入编译代码。 我们也会保存这个以备将来使用。 我们需要将拼图哈希编码成一个地址。 运行 `cdv encode --prefix txch` 并输入拼图哈希。 03:20\ -That gives us the puzzle address. Now we'll send an amount of chia to this address to lock it. And we'll check the status. Once confirmed, we'll be ready to spend it. +这给了我们拼图地址。 现在，我们将发送一定量的 chia 到这个地址以锁定它。 然后我们会检查状态。 一旦确认，我们就可以花费它了。 03:40\ -To spend the coin, we'll need to create a spend bundle. Take a look at this outline. this should look familiar to the spend bundle we created in the previous video. We'll need four things, the coin record, the puzzle reveal which we already calculated, the solution we want to provide, and an aggregated signature to authorize our spend. +要花费这个币，我们需要创建一个花费包。 看一下这个大纲。 这应该看起来很熟悉，就像我们在上一个视频中创建的花费包一样。 我们需要四件东西，币记录，我们已经计算过的拼图展示，我们想要提供的解决方案以及一个聚合签名来授权我们的花费。 04:00\ -To get the coin record, run `cdv rpc coinrecords --by puzzlehash` and enter the puzzle hash from earlier. Copy the coin object and paste it into the spend bundle template. Next we can enter the puzzle reveal we calculated earlier. For the solution, we're going to have to so some work. +要获取币记录，请运行 `cdv rpc coinrecords --by puzzlehash`，并输入之前的拼图哈希。 复制币对象，并将其粘贴到花费包模板中。 接下来，我们可以输入我们之前计算过的拼图展示。 对于解决方案，我们将需要做一些工作。 04:20\ -We'll use the standard condition `CREATE_COIN` to unlock the value of the coin and send it back to our wallet. To do that, we'll need our address which we can get with `chia wallet get address` and decode it to get the wallet address puzzle hash with `cdv decode` and our address. +我们将使用标准条件 `CREATE_COIN` 来解锁币的价值，并将其发送回我们的钱包。 为此，我们需要我们的地址，我们可以使用 `chia wallet get address` 获取，然后解码以获取钱包地址拼图哈希，并使用 `cdv decode` 和我们的地址。 04:40\ -To craft the solution, we'll run this command where `51` is the `CREATE_COIN` condition code, our wallet address puzzle hash, and an amount in mojo. We can enter this response into the solution of our spend bundle. +为了制作解决方案，我们将运行此命令，其中 `51` 是 `CREATE_COIN` 条件代码，我们的钱包地址拼图哈希，以及一个以 mojo 为单位的金额。 我们可以将此响应输入到我们的花费包的解决方案中。 05:00\ -Finally, the aggregated signature. Remember that the message we are signing is the tree hash of our conditions; or our solution. So first, let's generate that hash. Next we'll also need the coin ID and the genesis challenge. The genesis challenge is a standard value for each network. +最后，聚合签名。 请记住，我们正在签名的消息是我们的条件的树哈希；或我们的解决方案。 首先，让我们生成该哈希。 接下来，我们还需要币 ID 和起源挑战。 起源挑战是每个网络的标准值。 05:20\ -You can find the appropriate challenge by entering `chia show -s` and searching for 'genesis challenge'. Since we're on testnet10, our challenge is this value starting with 'AE'. For the coin ID, we actually need the parent ID, the puzzle hash, and the amount which can all be found in the coin record we copied earlier. +你可以通过输入 `chia show -s` 并搜索 'genesis challenge' 来找到适当的挑战。 对于币 ID，实际上我们需要父 ID、拼图哈希和金额，这些都可以在我们之前复制的币记录中找到。 05:40\ -To get the coin ID, we'll run `cdv inspect -id coins` enter the parent ID, the puzzle hash, and the amount. (`cdv inspect -id coins --parent-id [PARENT_ID] --puzzle-hash [PUZZLE_HASH] --amount [AMOUNT]`) The `AGG_SIG_ME` condition expects the concatenation of the conditions treehash, coin ID, and genesis challenge, so run +要获取币 ID，我们将运行 `cdv inspect -id coins`，然后输入父 ID、拼图哈希和金额。 （`cdv inspect -id coins --parent-id [PARENT_ID] --puzzle-hash [PUZZLE_HASH] --amount [AMOUNT]`）`AGG_SIG_ME` 条件期望条件树哈希、币 ID 和起源挑战的连接，因此运行 06:00\ -`concat` the conditions treehash, coin ID, and genesis challenge. Make sure to use the prefix `0x` to signify that these are values. Now let's sign this message and since we're NOT using it as a value, remember to remove the `0x` prefix this time. +`concat` 条件树哈希、币 ID 和起源挑战。 确保使用前缀 `0x` 表示这些都是值。 现在让我们对此消息进行签名，并且由于我们没有将其用作值，请记住这次删除 `0x` 前缀。 06:20\ -Now we can enter this signature into our spend bundle and push it. Run `cdv rpc pushtx spendbundle.json`. If your signature is incorrect, you'll get a failure message. Otherwise, congratulations! You've created a smart coin secured with a signature and spent it. +现在我们可以将此签名输入到我们的花费包中并进行推送。 运行 `cdv rpc pushtx spendbundle.json`。 如果您的签名不正确，您将收到一个失败消息。 否则，恭喜！ 您已经创建了一个智能币，并使用签名进行了保护。 06:40\ -So we've talked in this video about how signatures work, their importance, and how to implement them into a smart coin. Thanks so much for watching, I'll see you next time. +在本视频中，我们讨论了签名的工作原理、它们的重要性以及如何将它们实现到智能币中。 非常感谢观看，我们下次见。
--- -## Common gotchas +## 常见问题 -- **0x Prefixes:** It's important to keep track of how we are using different values and understand how Chialisp is going to handle them. A common gotcha is forgetting to append `0x` to a value, or in some cases removing it to tell the puzzle how to properly handle the parameter. -- **"Saving for Later":** At several points in this lesson, we generate results that we'll need to use elsewhere, sometimes many times. These results also do not have obivious indicators as to what they are. It's helpful to have a document to temporarily store these results for later use. +- **0x 前缀：** 重要的是要跟踪我们如何使用不同的值，并了解 Chialisp 将如何处理它们。 一个常见的小错误是忘记向值附加 `0x`，或在某些情况下将其删除以告诉拼图如何正确处理参数。 +- **“暂存以备后用”：** 在本课程的几个地方，我们生成了需要在其他地方使用的结果，有时候是多次。 这些结果也没有明显的指示符表明它们是什么。 为了以后使用，将这些结果临时保存在一个文件中是很有帮助的。 --- -## Knowledge check +## 知识检测 -:::tip Question 1 - Keys +:::tip 问题 1 - 密钥 -True or False. You need to use someone's private key to lock up a coin for them to spend. +正确还是错误。 你需要使用某人的私钥来锁定一枚硬币，以便他们能够花费。 ::: @@ -114,13 +114,13 @@ True or False. You need to use someone's private key to lock up a coin for them Answer (expand when ready to see the answer) -False. You would use their public key. Private keys are to be kept secret and never revealed to anyone. +错误 你应该使用他们的公钥。 私钥应保密，永远不应透露给任何人。
-:::tip Question 2 - Aggregate Signature +:::tip 问题 2 - 聚合签名 -An Aggregated Signature is comprised of which three components? +聚合签名由哪三个部分组成？ ::: @@ -128,23 +128,23 @@ An Aggregated Signature is comprised of which three components? Answer (expand when ready to see the answer) -The `AGG_SIG_ME` condition expects a concatenated value of the following: +`AGG_SIG_ME`条件期望以下值的串联： -1. The conditions treehash. -2. The coin ID. -3. The genesis challenge. +1. 条件的树哈希。 +2. 币的ID。 +3. 创世挑战。
--- -## Additional resources +## 附加资源 -### Runnable Chialisp and clvm plugins +### 可运行的Chialisp和clvm插件 -For information on using these plugins please refer to the [academy overview](/academy-overview#runnable-chialisp-and-clvm-plugins) +有关使用这些插件的信息，请参阅[学院概述](/academy-overview#可运行的chialisp和clvm插件)。 -#### Chialisp plugin +#### Chialisp 插件 @@ -156,7 +156,7 @@ For information on using these plugins please refer to the [academy overview](/a -#### Clvm plugin +#### Clvm插件 @@ -166,11 +166,11 @@ For information on using these plugins please refer to the [academy overview](/a -### Links +### 链接 -- General [chialisp concepts](https://docs.chia.net/guides/chialisp-concepts): overviews of currying, inner puzzles, and morphing conditions. -- Guided [chialisp walkthroughs](https://docs.chia.net/guides/): guides for installation, creating smart coins, and working with BLS signatures. -- Chialisp [detailed documentation](https://chialisp.com/): detailed information on all aspects of chialisp. +- [Chialisp基本概念](https://docs.chia.net/guides/chialisp-concepts)：包括柯里化（currying）、内部谜题（inner puzzles）和条件变换（morphing conditions）的概述。 +- 指导性的[Chialisp演练](https://docs.chia.net/guides/)：安装、创建智能币和使用BLS签名的指南。 +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-smart-coin.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-smart-coin.md index 9241966bf7..f339247361 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-smart-coin.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-smart-coin.md @@ -5,17 +5,17 @@ slug: /chialisp-smart-coin import Runnable from '@site/src/components/Runnable.tsx'; -In this lesson, we go over currying, hashing, and conditions, and submit and use our first Chia Smart Coin. +在本课程中，我们将讨论柯里化、哈希和条件，并提交并使用我们的第一个 Chia 智能硬币。 -## Learning objectives +## 学习目标 -- **Currying**: Understand how to create more general use puzzle by using Currying. -- **Hashing**: Understand the need to obfuscate sensitive portions of a puzzle by using Hashing. -- **Conditions**: Using conditions to allow the spender of the coin to decide how it is spent. +- **Currying（柯里化）**：了解如何通过柯里化创建更通用的谜题。 +- **Hashing（哈希）**：了解通过哈希来混淆谜题中的敏感部分的必要性。 +- **Conditions（条件）**：使用条件允许花费者决定如何花费币。 --- -## Content +## 内容
@@ -23,95 +23,95 @@ In this lesson, we go over currying, hashing, and conditions, and submit and use --- -## Script +## 脚本
Expand for the full script 00:00\ -Everything on a blockchain is a coin. They are often referred to as smart coins because every coin has a chialisp program associated with it. That program, known as the puzzle, decides how and when the coin can be spent, and what happens when it is. +在区块链上，一切都是一个币。 它们通常被称为智能硬币，因为每个币都与一个称为谜题的Chialisp程序相关联。 该程序决定了币何时以及如何被使用，以及在使用时会发生什么。 00:20\ -NFTs, CATs, and standard transactions are all defined using puzzles. In the previous video, we learned how to write basic chialisp programs. Let's apply that to some more complex puzzles and create a coin that can be spent on the blockchain. +NFT、CAT 和标准交易都使用谜题来定义。 在上一个视频中，我们学习了如何编写基本的Chialisp程序。 让我们将这些应用到一些更复杂的谜题中，并创建一个可以在区块链上使用的币。 00:40\ -In this video, we'll be talking about currying, hashing, and conditions. So let's get started! We'll start by creating a new chialisp file called `password.clsp` and create a module that takes a parameter `password` and determines if the value passed in equals `hello`. If it does, return correct, if not return incorrect. +在这个视频中，我们将讨论柯里化、哈希和条件。 那么让我们开始吧！ 我们将首先创建一个名为 `password.clsp` 的新Chialisp文件，并创建一个模块，它接受一个参数 `password` 并确定传入的值是否等于 `hello`。 如果是，则返回 "correct"，否则返回 "incorrect"。 01:00\ -We'll run this using the `brun` command in our terminal and pass in `hello` which should give us a success. Just to test the opposite, we'll pass in something else, and see if that fails. So this is a bit of a refresher on chialisp basics. One of the issues we have with a puzzle like this is that the hard-coded value for the password is both insecure and not very useful. +我们将在终端中使用 `brun` 命令运行这个，并传入 `hello`，这应该会给我们一个成功。 为了测试相反的情况，我们将传入其他内容，然后看看是否失败。 这是对Chialisp基础知识的一点复习。 我们这个谜题的一个问题是，密码的硬编码值既不安全也不太有用。 01:20\ -We'd like to have a generalized puzzle that we can use for any password we choose to have. For this we'll use currying and hashing. To make this puzzle more generalized, we will be using currying. To do so, let's replace our password parameter with two new ones, `CORRECT_PASSWORD` and `provided_password`, and then run our comparison on those parameters. +我们想要一个更通用的谜题，可以用于任何我们选择的密码。 为此，我们将使用柯里化和哈希。 为了使这个谜题更通用，我们将使用柯里化。 为此，让我们用两个新的参数替换我们的密码参数，`CORRECT_PASSWORD` 和 `provided_password`，然后在这些参数上运行我们的比较。 01:40\ -Now in our terminal, we can curry in a value to replace the correct password parameter and compile it. Run `cdv clsp curry password.clsp -a` and pass in our desired password, in this case - `hello` and we get the following result. Now if we run that through `brun` and give it the correct password, we should get a success. +现在在我们的终端中，我们可以柯里化一个值来替换正确的密码参数并进行编译。 运行 `cdv clsp curry password.clsp -a`，并传入我们想要的密码，这里是 `hello`，我们会得到以下结果。 现在如果我们通过 `brun` 运行它，并给它正确的密码，我们应该会得到一个成功。 02:00\ -We can also nest these commands like this - (`brun "$(cdv clsp curry password.clsp -a 'goodbye')" "(goodbye)"`). The first steps to making our puzzle more secure is to use hashing. A hash function will take an input and return a hash value. One of the most popular hashing algorithms is sha256 which is directly supported within chialisp. +我们也可以像这样嵌套这些命令 - (`brun "$(cdv clsp curry password.clsp -a 'goodbye')" "(goodbye)"`)。 使我们的谜题更安全的第一步是使用哈希。 A hash function will take an input and return a hash value. 最流行的哈希算法之一是 sha256，它直接在chialisp中支持。 02:20\ -A few important notes about hash functions; given a value, calculating the hash is extremely easy. Given a hash, calculating the original input is extremely difficult or impossible, and passing the same value through a hashing function multiple times will always result in the same output. +关于哈希函数的几个重要说明：给定一个值，计算哈希非常容易。 给定一个哈希，计算原始输入非常困难或不可能，并且通过哈希函数多次传递相同的值将始终产生相同的输出。 02:40\ -We can use these principles to our advantage by currying a hash of the expected password instead of the password value itself. This prevents us from revealing the expected password while still allowing us to check if the provided password is correct. This is done by hashing the provided password. So let's change our puzzle to use hashing. +我们可以利用这些原则，通过柯里化预期密码的哈希值而不是密码值本身来提高安全性。 This prevents us from revealing the expected password while still allowing us to check if the provided password is correct. This is done by hashing the provided password. 所以让我们改变我们的谜题来使用哈希。 03:00\ -First, change the curried parameter to `PASSWORD_HASH` and change the other parameter to `password`. In the comparison, use sha256 to hash the given password and compare it to the password hash. To test this we'll first have to hash a password and curry it into our new puzzle. +首先，将柯里化参数更改为 `PASSWORD_HASH`，并将其他参数更改为 `password`。 在比较中，使用 sha256 来哈希给定的密码，并将其与密码哈希进行比较。 为了测试这个，我们首先需要对密码进行哈希并将其柯里化到我们的新谜题中。 03:20\ -Run `cdv hash "hello"` to get the hash for the password 'hello'. We can now curry this into our puzzle like last time, making sure to prefix the hash with `0x` to identify it as a chialisp value. Now we can pass this compiled puzzle through `brun` and provide the correct password to test. +运行 `cdv hash "hello"` 来获取密码 "hello" 的哈希。 现在我们可以像上次一样将其柯里化到我们的谜题中，确保用 `0x` 前缀标识为chialisp值。 现在我们可以通过 `brun` 传递这个编译后的谜题，并提供正确的密码进行测试。 03:40\ -It's important to know that while hashing is an essential part of securing our puzzle, this is not quite enough. When we provide our solution with the correct password, that password will be visible on the blockchain. Meaning we won't be able to use it again. The final solution to this problem is to use signatures, which we'll talk about in a future video. Now that we've talked about currying and hashing, let's talk about conditions. +重要的是要知道，虽然哈希是确保我们的谜题安全的重要部分，但这还不够。 当我们用正确的密码提供我们的解决方案时，该密码将在区块链上可见。 这意味着我们将无法再次使用它。 解决这个问题的最终方法是使用签名，我们将在未来的视频中讨论。 现在我们已经讨论了柯里化和哈希，让我们谈谈条件。 04:00\ -In our password puzzle, let's make a couple of additions. First, we'll add a parameter called conditions and then replace the success and fail messages with that parameter, followed by `(x)`. So what does this do? Well the `x` represents an error. If the password is incorrect, the if statement will evaluate to false and error out, terminating the program and leaving the coin that we are creating unspent. +在我们的密码谜题中，让我们做一些添加。 首先，我们将添加一个名为 `conditions` 的参数，然后用该参数替换成功和失败消息，后跟 `(x)`。 那么这是做什么的呢？ 好吧，`x` 代表错误。 如果密码不正确，if 语句将计算为 false，并且出错，终止程序，并使我们创建的币未花费。 04:20\ -If the correct password is given, the conditions that are provided by the spender will be run. So back to our terminal, first we'll need to curry in our hashed password as before. Now that we have the compiled puzzle, we're going to need to do a few things to create the coin. First, we'll need the puzzle hash which we can get by running `opc -H` and passing in our compiled puzzle. +如果给出正确的密码，则conditions 提供者提供的条件将会执行。 回到我们的终端，首先我们需要像之前一样柯里化我们的哈希密码。 现在我们有了编译后的谜题，我们需要做一些事情来创建币。 首先，我们需要谜题哈希，我们可以通过运行 `opc -H` 并传入我们的编译后的谜题来获得。 04:40\ -We'll save the result for later. Next, we'll need the puzzle reveal which is just a serialized form of the puzzle in hex. It's what you must reveal on chain when spending a coin. We can get this by running `opc` and passing in our compiled puzzle. We'll save this for later as well. +我们将保存结果供以后使用。 接下来，我们需要谜题揭示，它只是谜题的十六进制序列化形式。 这是在花费币时必须在链上揭示的内容。 我们可以通过运行 `opc` 并传入我们的编译后的谜题来获得这个。 我们也会保存这个以备将来使用。 05:00\ -Now to create the coin, we need to encode our puzzle hash into an address with `cdv encode -p txch` and passing in our puzzle hash. We then send that address an amount of xch to lock it. Now let's spend the coin to release value back to our wallet. First, we'll get our wallet address and convert it to a puzzle hash with `cdv decode`. +现在要创建币，我们需要将我们的谜题哈希编码为一个地址，使用 `cdv encode -p txch` 并传入我们的谜题哈希。 然后我们将给该地址发送一定数量的 xch 以锁定它。 现在让我们花费币以释放价值回到我们的钱包。 首先，我们将获取我们的钱包地址，并使用 `cdv decode` 将其转换为谜题哈希。 05:20\ -We'll then use this to build the condition we want to pass into the coin. For this example, we're going to use the `CREATE_COIN` condition which is denoted by the code `51`. So to construct our solution, we'll write `opc` then give our password, then the condition we want to pass in. +接下来，我们将使用这个来构建我们要传递到币中的条件。 对于本例，我们将使用代号为 `51` 的 `CREATE_COIN` 条件。 因此，为了构建我们的解决方案，我们将写 `opc` 然后给出我们的密码，然后是我们要传递的条件。 05:40\ -In this case, the condition code `51`, our wallet puzzle hash - prefixed by `0x`, and an amount. This output is our solution and we'll save it for later. All right, we now need to retrieve the coin record we created earlier when we committed xch to the puzzle. Run `cdv rpc coinrecords --by puzzlehash` and pass in the original puzzle hash. +在这种情况下，条件代码 `51`，我们的钱包谜题哈希 - 前缀为 `0x`，以及一个数量。 这个输出就是我们的解决方案，我们会将其保存供以后使用。 好的，现在我们需要检索我们之前创建的币记录，当我们将 xch 承诺给谜题时。 运行 `cdv rpc coinrecords --by puzzlehash` 并传入原始谜题哈希。 06:00\ -The output may contain a few coin records depending on if you're following the example closely and use the most recent one based on highest block index, and copy the coin record. Now we are going to create a spend bundle. Start a `json` file and create a property called `coin_spends` that contains an array containing an object. (`[{}]`) +输出可能会包含一些币记录，具体取决于您是否紧密遵循示例，并根据最高区块索引选择最近的一个，并复制币记录。 现在我们将创建一个花费捆绑包。 开始一个 `json` 文件，并创建一个名为 `coin_spends` 的属性，其中包含一个包含一个对象的数组。 (`[{}]`) 06:20\ -Paste the coin record, followed by the puzzle reveal you generated earlier, and then the solution. Create another property called `aggregated_signature` and assign this value (`0xc0000000000...`) That's 191 zeros. Now submit the spend bundle to the mempool with `cdv rpc pushtx spendbundle.json`. +粘贴币记录，然后是您之前生成的谜题揭示，然后是解决方案。 创建另一个名为 `aggregated_signature` 的属性，并将其分配为这个值（`0xc0000000000...`）这是 191 个零。 现在将花费捆绑包提交到内存池中，使用 `cdv rpc pushtx spendbundle.json`。 06:40\ -If everything was successful, this transaction should be accepted and you should see your wallet balance increase after some time passes. Now you've created your first smart coin. In this video, we talked about how to curry values into a generalized puzzle, how to hash both sensitive values as well as puzzles for creating coins, and touched on conditions that can be passed into puzzles. +如果一切顺利，此交易应该被接受，一段时间后您应该会看到您的钱包余额增加。 现在您已经创建了您的第一个智能币。 在本视频中，我们讨论了如何将值柯里化到通用谜题中，如何对敏感值以及用于创建币的谜题进行哈希，并简要介绍了可以传递到谜题中的条件。 07:00\ -In the next video, we'll talk further about security and how to use signatures to better secure your transactions. See you then. +在下一个视频中，我们将进一步讨论安全性以及如何使用签名来更好地保护您的交易。 那时再见。
--- -## Common gotchas +## 常见问题 -- **Curried parameters:** It's considered best practice to write parameters that are intended to be curried in in all caps. This helps keep track of where each parameter is coming from while writing the puzzle. -- **0x Prefixes:** It's important to keep track of how we are using different values and understand how Chialisp is going to handle them. A common gotcha is forgetting to append `0x` to a value, or in some cases removing it to tell the puzzle how to properly handle the parameter. -- **Condition Codes:** Condition codes are by default signified by a numerical code. In future lessons, we will also use a library that allows us to reference the codes with more descriptive language. +- **柯里化参数：** 最佳实践是将意图进行柯里化的参数写成大写字母。 这有助于在编写谜题时跟踪每个参数的来源。 +- **0x 前缀：** 重要的是要跟踪我们如何使用不同的值，并了解 Chialisp 将如何处理它们。 一个常见的小错误是忘记向值附加 `0x`，或在某些情况下将其删除以告诉拼图如何正确处理参数。 +- **条件代码：** 条件代码默认用数字代码表示。 在未来的课程中，我们还将使用一个允许我们使用更具描述性语言引用代码的库。 --- -## Knowledge check +## 知识检测 -:::tip Question 1 - Curried Parameters +:::tip 问题 1 - 柯里化参数 -Which parameter in this puzzle will be curried in? +在这个谜题中，哪个参数将被柯里化进去？ ```chialisp (mod (ARG1 arg2) @@ -128,15 +128,15 @@ Which parameter in this puzzle will be curried in? Answer (expand when ready to see the answer) -ARG1 will be curried in. +ARG1 将被柯里化进去。 -Currying always substitutes parameters in order, so when currying, the first will be replaced. Best practice is to write a curried parameter in all caps to help us keep track. +柯里化始终按顺序替换参数，因此在柯里化时，第一个将被替换。 最佳实践是将柯里化的参数用大写字母写出，以帮助我们跟踪。
-:::tip Question 2 - Hashing Principles +:::tip 问题 2 - 哈希原理 -What are the three principles of hashing? +哈希的三个原理是什么？ ::: @@ -144,15 +144,15 @@ What are the three principles of hashing? Answer (expand when ready to see the answer) -1. Given a value, hashing that value is computationally easy -2. Given a hash, calculating the value is computationally difficult or impossible -3. Hashing the same input, will result in the same output +1. 给定一个值，对该值进行哈希是计算上容易的。 +2. 给定一个哈希，计算出原始值是计算上困难或不可能的。 +3. 对相同的输入进行哈希，将会得到相同的输出。
-:::tip Question 3 - Hashing Puzzle +:::tip 问题 3 - 哈希谜题 -True or False. Sha256 is one of the most popular hashing algorithms and is natively supported by chialisp. +正确还是错误。 Sha256是最流行的哈希算法之一，并且在chialisp 中得到了原生支持。 ::: @@ -164,13 +164,13 @@ True
-:::tip Question 4 - Combining all of the above +:::tip 问题 4 - 结合上述所有内容 -Write a Chialisp puzzle that performs the following. +编写一个 Chialisp 谜题，执行以下操作。 -- Accepts a curried parameter -- Hashes a provided parameter with sha256 and compares it to the curried parameter. -- Outputs a provided result if the comparison is true. +- 接受一个柯里化参数 +- 使用sha256哈希提供的参数，并将其与柯里化参数进行比较。 +- 如果比较结果为真，则输出提供的结果。 ::: @@ -191,13 +191,13 @@ Write a Chialisp puzzle that performs the following. --- -## Additional resources +## 附加资源 -### Runnable Chialisp and clvm plugins +### 可运行的Chialisp和clvm插件 -For information on using these plugins please refer to the [academy overview](/academy-overview#runnable-chialisp-and-clvm-plugins) +有关使用这些插件的信息，请参阅[学院概述](/academy-overview#可运行的chialisp和clvm插件)。 -#### Chialisp plugin +#### Chialisp 插件 @@ -209,7 +209,7 @@ For information on using these plugins please refer to the [academy overview](/a -#### Clvm plugin +#### Clvm插件 @@ -219,11 +219,11 @@ For information on using these plugins please refer to the [academy overview](/a -### Links +### 链接 -- General [chialisp concepts](https://docs.chia.net/guides/chialisp-concepts): overviews of currying, inner puzzles, and morphing conditions. -- Guided [chialisp walkthroughs](https://docs.chia.net/guides/): guides for installation, creating smart coins, and working with BLS signatures. -- Chialisp [detailed documentation](https://chialisp.com/): detailed information on all aspects of chialisp. +- [Chialisp基本概念](https://docs.chia.net/guides/chialisp-concepts)：包括柯里化（currying）、内部谜题（inner puzzles）和条件变换（morphing conditions）的概述。 +- 指导性的[Chialisp演练](https://docs.chia.net/guides/)：安装、创建智能币和使用BLS签名的指南。 +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/challenges-plot-filters.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/challenges-plot-filters.md index c0c8c742fd..23441312cc 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/challenges-plot-filters.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/challenges-plot-filters.md @@ -1,18 +1,18 @@ --- -title: Challenges & Plot Filters +title: 挑战和图块初筛 slug: /challenges-plot-filters --- -In this lesson, we discuss how the plot filter works, and what the benefits are of using one. +在本课中，我们将讨论图块初筛的工作原理，以及使用它的好处。 -## Learning objectives +## 学习目标 -- **Plot Filters**: Understand the basics of how the plot filter works, as well as the benefits of using one. -- **Challenge Generation**: Understand how the challenge is generated by the Timelord and sent to the Farmer. +- **图块初筛**：了解图块初筛的基本工作原理及其使用的好处。 +- **挑战生成**：了解时间领主（Timelord）如何生成挑战并将其发送给农民。 --- -## Content +## 内容
@@ -20,39 +20,39 @@ In this lesson, we discuss how the plot filter works, and what the benefits are --- -## Script +## 脚本
Expand for the full script 0:00\ -The Timelord generates a new challenge about every 9 seconds. This is then hashed with the ID of each plot. +时间领主大约每9秒生成一个新挑战。 然后将其与每个图块的ID进行哈希处理。 0:20\ -If the hash starts with 9 zeroes, the plot is considered eligible for harvesting. This is called the plot filter. The Plot Filter serves as a decentralizing force to further randomize the winner, as well as reduce the total compute needed for each challenge. +如果哈希值以9个零开头，该图块被认为有资格进行收割。 这称为图块初筛。 图块初筛作为去中心化的力量，进一步随机化赢得区块的农民，并减少每个挑战所需的总计算量。 0:40\ -When a farmer receives a challenge, the harvester first determines which plots are valid and pass the plot filter, then produces potential proofs of space and submits them to the Timelord for verification and review. +当农民收到挑战时，收割者首先确定哪些图块是有效的并通过图块初筛，然后生成潜在的空间证明并提交给时间领主进行验证和审查。 1:00\ -The Timelord will choose the Proof of Space that most closely meets the challenge, and using the challenge and provided Proof of Space as inputs, runs a VDF to prove that time has passed and produces the next challenge. +时间领主将选择最符合挑战的空间证明，并使用挑战和提供的空间证明作为输入，运行一个VDF来证明时间已经过去，并生成下一个挑战。
--- -## Common gotchas +## 常见问题 -- **Are valid proofs filtered out?:** It is very possible that a valid proof of space would be contained in a filtered plot. This affects every farmer equally though, and the benefits of further decentralization are well worth it. +- **有效证明会被过滤掉吗？**：一个有效的空间证明很可能会包含在被过滤掉的图块中。 然而，这对每个农民的影响是平等的，并且进一步去中心化的好处是非常值得的。 --- -## Knowledge check +## 知识检测 -:::tip Question 1 - Challenge Frequency +:::tip 问题1 - 挑战频率 -About how often will a Timelord generate a new challenge? +时间领主大约每隔多久生成一个新的挑战？ ::: @@ -60,13 +60,13 @@ About how often will a Timelord generate a new challenge? Answer (expand when ready to see the answer) -`"About every 9 seconds"` +大约每9秒钟 -:::tip Question 2 - Filter Benefits +:::tip 问题2 - 初筛的好处 -What are the two significant benefits of using a plot filter? +使用图块初筛的两个重要好处是什么？ ::: @@ -74,22 +74,20 @@ What are the two significant benefits of using a plot filter? Answer (expand when ready to see the answer) -```bash -1. It further decentralizes the network. -2. It reduces the amount of compute needed, improving network efficiency -``` +1. 进一步去中心化了网络。 +2. 它减少了所需的计算量，提高了网络的效率。 --- -## Additional resources +## 附加资源 -### Links +### 链接 -- More [farming basics](https://docs.chia.net/farming-basics): overviews of plotting, pooling, and rewards. -- In depth [architecture overview](https://docs.chia.net/architecture-overview): describing the interactions between Farmers, Harvesters, Wallets, etc. -- Chialisp [detailed documentation](https://chialisp.com/): detailed information on all aspects of chialisp. +- 更多的[耕种基础知识](https://docs.chia.net/farming-basics)：绘图、矿池和奖励的概述。 +- 详细的[架构概述](https://docs.chia.net/architecture-overview)：描述农民、收割机、钱包等之间的交互。 +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/farming-overview.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/farming-overview.md index 34bbbde9af..47326d025c 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/farming-overview.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/farming-overview.md @@ -1,18 +1,18 @@ --- -title: Farming Overview +title: 耕种概览 slug: /farming-overview --- -In this lesson, we go over the plotting process, and what happens when a Farmer wins a challenge. +在本课程中，我们将介绍绘图过程，以及当农名赢得挑战时会发生什么。 -## Learning objectives +## 学习目标 -- **Protocols**: Understand the basics of the Chia Farming protocol. -- **Puzzles and Solutions**: Understand the use of puzzles and solutions in Chialisp. +- **协议**：了解Chia耕种协议的基础知识。 +- **谜题（Puzzles）和解决方案（Solutions）**：了解谜题和解决方案在Chialisp中的使用。 --- -## Content +## 内容
@@ -20,43 +20,43 @@ In this lesson, we go over the plotting process, and what happens when a Farmer --- -## Script +## 脚本
Expand for the full script 0:00\ -Farmers are nodes that seek to win Proof of Space challenges in exchange for rewards. The Farmer that wins a challenge constructs and processes a block of transactions and adds it to the blockchain. +农民（Farmers）是寻求赢得空间证明挑战以换取奖励的节点。 赢得挑战的农民会构建并处理一个交易区块，并将其添加到区块链中。 0:20\ -To start, the Farmers pre-generate hashes into large blocks called Plots. The size of these plots are determined by a constant, k. k32 is the minimum required size and equates to around 108GB per plot. +首先，农民预先生成哈希值到称为图块（Plots）的大块（large blocks）中。 这些图块的大小由一个常数k决定，k32是所需的最小尺寸，相当于每个图块约108GB。 0:40\ -This plotting process is computationally intensive, similar to classic blockchain "mining", however, this process is only done once, reducing the overall energy usage immensely. Once the plots are created, they are then passively monitored by harvesters to determine if they contain a valid Proof of Space for the current network challenge. +这个绘图过程计算密集，类似于传统区块链的“挖矿”，但这个过程只需要进行一次，大大减少了整体能耗。 一旦图块创建完成，它们会被农民被动监控，以确定它们是否包含当前网络挑战的有效空间证明。 1:00\ -If the Farmer wins the challenge, they will start filling a block with transactions from the mempool. The Farming client has control of which transactions to include in the block, and will usually choose based on the largest Farming Fee, adding to the overall reward received. +如果农民赢得了挑战，他们将开始从内存池中填充交易到区块中。 耕种客户端将控制哪些交易可以包含到区块中，通常会根据最高的耕种手续费用来做选择，从而增加总奖励。 1:20\ -The block is then processed, meaning all the transactions and programs within smart coins are executed and resolved. The block is then signed by the farmer and submitted to the chain. +然后处理该区块，意味着所有交易和智能币中的程序都会被执行和解决。 区块随后由农民签名并提交到链上。
--- -## Common gotchas +## 常见问题 -- **Continuous Harvesting:** Plots do not need to be continuously created. A Farmer can create many plots all at once, and continuously harvest from those plots well into the future. The plots will remain valid and in use even after a proof of space has been found. -- **Choosing Transactions:** Transactions are stored temporarily in the "mempool" and are retrieved by a winning Farmer to create a block. The transactions can be chosen to maximize the reward a Farmer receives by prioritizing the transactions that include Farming Fees. This means that if a transaction doesn't include a Fee, there is a chance that it will not be included in a block even if it was created before the transactions that were. +- **持续收获**：图块不需要一直创建。 农民可以一次性创建许多图块，并在未来持续从这些图块中收获。 即使在找到空间证明之后，这些图块仍然有效并且可以使用。 +- **选择交易**：交易暂时存储在“内存池”中，获胜的农夫会从其中检索交易来创建区块。 可以通过优先选择包含耕种手续费的交易来最大化农民获得的奖励。 这意味着如果一笔交易没有包含手续费，即使它在其他包含手续费的交易之前创建，也有可能不会被包含在区块中。 --- -## Knowledge check +## 知识检测 -:::tip Question 1 - k Size +:::tip 问题1 - k值 -What is the minimum k size required by the Chia blockchain? +Chia区块链要求的最小k值是多少？ ::: @@ -64,13 +64,13 @@ What is the minimum k size required by the Chia blockchain? Answer (expand when ready to see the answer) -`"k32"` +k32 -:::tip Question 2 - Plot File Size +:::tip 问题2 - 图块文件大小 -How large is a plot file when using the minimum k-size, k32? +使用最小k值k32时，图块文件有多大？ ::: @@ -78,13 +78,13 @@ How large is a plot file when using the minimum k-size, k32? Answer (expand when ready to see the answer) -`"Around 108GB"` +大约108GB -:::tip Question 3 - Plotting Frequency +:::tip 问题3 - 绘图频率 -How often should a Farmer replot? +农民应该多长时间重新绘图一次？ ::: @@ -92,13 +92,13 @@ How often should a Farmer replot? Answer (expand when ready to see the answer) -`"Ideally, a Farmer should not have to replot. There may be some instances a Farmer may want to replot (alter the k-size or compression, changing from pool-based farming to solo-farming etc.), but the plots should remain valid and useful well into the future."` +理想情况下，农民不需要重新绘图。 农民可能在某些情况下会想要重新绘图(如改变k值或压缩率，从基于矿池的耕种改为独立耕种等)，但图块应长期保持有效和有用。 -:::tip Question 4 - Processing Smart Coins. +:::tip 问题4 - 处理智能币。 -True or False; When a block is created, the Timelord processes and evaluates all the contained smart coins. +真还是假；当一个区块被创建时，时间领主会处理和评估所有包含的智能币。 ::: @@ -106,19 +106,19 @@ True or False; When a block is created, the Timelord processes and evaluates all Answer (expand when ready to see the answer) -`"False. The Farmer processes the smart coins contained in the block. The Timelord infuses the block to the rest of the chain."` +错误 农民处理区块中包含的智能币。 时间领主将区块注入到链的其余部分。 --- -## Additional resources +## 附加资源 -### Links +### 链接 -- More [farming basics](https://docs.chia.net/farming-basics): overviews of plotting, pooling, and rewards. -- In depth [architecture overview](https://docs.chia.net/architecture-overview): describing the interactions between Farmers, Harvesters, Wallets, etc. -- Chialisp [detailed documentation](https://chialisp.com/): detailed information on all aspects of chialisp. +- 更多的[耕种基础知识](https://docs.chia.net/farming-basics)：绘图、矿池和奖励的概述。 +- 详细的[架构概述](https://docs.chia.net/architecture-overview)：描述农民、收割机、钱包等之间的交互。 +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/first-plot.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/first-plot.md index b3d8ccc8a4..9ef5901ece 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/first-plot.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/first-plot.md @@ -1,18 +1,18 @@ --- -title: Creating your first Plot +title: 创建第一个图块 slug: /first-plot --- -In this lesson, we learn how to set up the Chia client, sync our full node using a torrent file, and create our first plot to start farming. +在这节课中，我们将学习如何设置Chia客户端，使用种子文件同步我们的全节点，并创建第一个图块来开始耕种。 -## Learning objectives +## 学习目标 -- **Syncing a Full Node**: Learn how to set up the Chia client and sync a full node. -- **Plot Creation**: Learn how to create a plot. +- **同步全节点**：学习如何设置Chia客户端并同步全节点。 +- **图块创建**：学习如何创建一个图块。 --- -## Content +## 内容
@@ -20,25 +20,25 @@ In this lesson, we learn how to set up the Chia client, sync our full node using --- -## Common gotchas +## 常见问题 -- **Joining a pool before plotting:** It might seem strange to join a pool before setting up your plots, but the plots need to be generated using a plotnft in order for the pool to know who runs them. You must associate a plotnft with a pool if you want to use pooling, and if set up correctly you can always leave the pool later and farm your plots solo. +- **在创建图块之前加入矿池：** 在设置绘图之前加入矿池可能看起来有些奇怪，但图块需要使用农田（plot NFT）生成，以便矿池知道谁拥有它们。 如果你想使用矿池，你必须将农田与一个矿池关联起来，如果设置正确，你随时可以离开矿池，自己耕种你的图块。 --- -## Knowledge check +## 知识检测 -Follow along with the video, and start plotting! +跟随视频操作，开始创建图块吧！ --- -## Additional resources +## 附加资源 -### Links +### 链接 -- More [farming basics](https://docs.chia.net/farming-basics): overviews of plotting, pooling, and rewards. -- In depth [architecture overview](https://docs.chia.net/architecture-overview): describing the interactions between Farmers, Harvesters, Wallets, etc. -- Chialisp [detailed documentation](https://chialisp.com/): detailed information on all aspects of chialisp. +- 更多的[耕种基础知识](https://docs.chia.net/farming-basics)：绘图、矿池和奖励的概述。 +- 详细的[架构概述](https://docs.chia.net/architecture-overview)：描述农民、收割机、钱包等之间的交互。 +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/pools.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/pools.md index 9c4d53fe83..c082554f1f 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/pools.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/pools.md @@ -3,16 +3,16 @@ title: Pools slug: /pools --- -In this lesson, we review the Pooling protocol, and how it can benefit a Farmer starting out. +在本课程中，我们将回顾矿池协议，以及它如何有助于刚开始的农民。 -## Learning objectives +## 学习目标 -- **Benefits of Pooling**: Understand the benefits of participating in a Pool. -- **Reward Splitting**: Understand how the rewards are split among pool participants. +- **矿池的好处**：理解参与矿池（Pool）的好处。 +- **奖励分配**：理解奖励如何在矿池参与者之间分配。 --- -## Content +## 内容
@@ -20,39 +20,39 @@ In this lesson, we review the Pooling protocol, and how it can benefit a Farmer --- -## Script +## 脚本
Expand for the full script 0:00\ -Pools are a great way to get started with Farming. Pooling allows farmers to smooth out their rewards by earning based on proof of space partials, as opposed to winning blocks. +矿池是开始耕种的一个很好的方式。 通过参与矿池，农民可以通过基于空间证明的部分证明来平滑他们的奖励，而不是通过赢得区块来获取奖励。 0:20\ -A Proof of Space partial contains some additional metadata about the farmer that lets the Pool distribute shared rewards based on relative farm size. The more valid partials a farmer generates, the larger their share of the reward. When a submitted proof of space wins, the farmer that generated it still retains the right to farm the block, and processes it themselves. +一个空间证明的部分（Proof of Space partial ）包含一些关于农民的额外元数据，这使得矿池可以根据相对农场规模分配共享奖励。 农民生成的有效部分越多，他们获得的奖励份额就越大。 当提交的空间证明获胜时，生成它的农民仍保留生成该区块的权利，并自行处理它。 0:40\ -In return, they receive 1/8 the value of the reward, while the remaining 7/8 is distributed to the rest of the pool, based on valid partials. Because the block is still farmed by an individual farmer, the network remains sufficiently decentralized. +作为回报，他们获得奖励价值的1/8，剩余的7/8根据有效部分分配给矿池的其他成员。 因为区块仍由农民生成，所以网络保持足够的去中心化。 1:00\ -The overall reward earned is largely the same over time for average sized farms, so Pooling is a great choice to get started. +随着时间的推移，对于农民来说，总体获得的奖励基本相同，因此参与矿池是一个很好的选择。
--- -## Common gotchas +## 常见问题 -- **Farming size still matters:** The size of a Farm directly relates to how many valid partials are generated, and partials determine a farmers share of the pool reward (7/8). This means there is still a benefit to large farms joining a pool. +- **农场规模仍然重要：** 农场的规模直接影响生成的有效部分数量，而有效部分决定了农民在矿池奖励中的份额(7/8)。 这意味着大型农场加入矿池仍然具有好处。 --- -## Knowledge check +## 知识检测 -:::tip Question 1 - Reward Split +:::tip 问题1 - 奖励分配 -What is the reward split between the Farmer and the Pool? +农民和矿池之间的奖励分配是多少？ ::: @@ -60,13 +60,13 @@ What is the reward split between the Farmer and the Pool? Answer (expand when ready to see the answer) -`"1/8 goes to the Farmer who won the challenge, 7/8 goes to the pool to be distributed"` +1/8的奖励给赢得挑战的农民，7/8的奖励给矿池分配 -:::tip Question 2 - Decentralized Pooling +:::tip 问题2 - 去中心化矿池 -How does the protocol maintain decentralization? +这个协议如何保持去中心化？ ::: @@ -74,19 +74,19 @@ How does the protocol maintain decentralization? Answer (expand when ready to see the answer) -`"By letting the Farmers process and author blocks, the network remains decentralized. Since the pool has no way of knowing which Farmer will win, and does not have a say on which transactions will be included in the block."` +通过让农民处理和创建区块，网络保持去中心化。 因为矿池无法知道哪个农民会赢得挑战，并且无权决定哪些交易将被包含在区块中。 --- -## Additional resources +## 附加资源 -### Links +### 链接 -- More [farming basics](https://docs.chia.net/farming-basics): overviews of plotting, pooling, and rewards. -- In depth [architecture overview](https://docs.chia.net/architecture-overview): describing the interactions between Farmers, Harvesters, Wallets, etc. -- Chialisp [detailed documentation](https://chialisp.com/): detailed information on all aspects of chialisp. +- 更多的[耕种基础知识](https://docs.chia.net/farming-basics)：绘图、矿池和奖励的概述。 +- 详细的[架构概述](https://docs.chia.net/architecture-overview)：描述农民、收割机、钱包等之间的交互。 +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-cat.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-cat.md new file mode 100644 index 0000000000..4d4a3db0bf --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-cat.md @@ -0,0 +1,97 @@ +--- +title: CATs +slug: /academy-cat +--- + +In this lesson, we talk about Chia Asset Tokens, and how they can be used. + +## 学习目标 + +- **Issuance**: Understand the basic types of issuance rules. + +--- + +## 内容 + +
+ +
+ +--- + +## 脚本 + +
+ + Expand for the full script + +0:00\ +A Chia Asset Token, or CAT, is a type of fungible token that can be minted from XCH. These tokens can take many different forms from a separate form of currency, to representing a collection of identical assets. + +0:20 +A CAT can have different properties, determined by it's TAIL, or Token Asset Issuance Limiter. This TAIL determines how the CAT is issued, how it can be subsequently spent, and whether it can be melted back into XCH. + +0:40 +A CAT wraps an inner puzzle that controls ownership of the coin. This is typically the standard transaction puzzle to facilitate sending the CATs to a Chia wallet. For the TAIL, there are 2 standard puzzles, Single-Issuance, and Multi-Issuance. +The Single-Issuance TAIL is more restrictive and is designed to make sure the supply is maintained. + +1:00 +With this TAIL, only the CATs minted at creation are valid, and they cannot be melted back into XCH. +The Multi-Issuance TAIL allows more identical CATs to be issued in the future, as long as the original issuance key is used. This is useful if the total number of tokens needed is unknown. + +1:20 +While these are the standard puzzles, a TAIL can be customized to allow any desired behavior. + +
+ +--- + +## 常见问题 + +- **Fungibility:** CATs are fungible, meaning they can be exchanged for each other at will. There are no editions, lot numbers, or anything else that would differentiate two CATs from the same issuance. +- **Melting:** Melting a CAT (if allowed by the TAIL) converts the underlying value of the CAT back to XCH which can then be used for other coins. A CAT can only ever be melted into the same amount of XCH used to create the CAT. + +--- + +## 知识检测 + +:::tip Question 1 - CATs vs. NFTs + +True or False; A CAT is a special type of NFT. + +::: + +
+ + Answer (expand when ready to see the answer) + +错误 A CAT is fungible, whereas an NFT is non-fungible and represents a unique item. + +
+ +:::tip Question 2 - TAILs + +What are the standard types of TAILs? + +::: + +
+ + Answer (expand when ready to see the answer) + +Single-Issuance and Multi-Issuance. + +
+ +--- + +## 附加资源 + +### 链接 + +- More about [primitives](https://docs.chia.net/guides/primitives/): guides for each primitive, and how to use them. +- In depth [CAT overview](https://docs.chia.net/guides/cat-creation-tutorial/): describing the CAT standard, and how to issue them. +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 +- Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-did.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-did.md new file mode 100644 index 0000000000..58cb382aa3 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-did.md @@ -0,0 +1,89 @@ +--- +title: DIDs +slug: /academy-did +--- + +This lesson is an overview of DIDs. + +## 学习目标 + +- **Identity Ownership**: Understand the differences in data ownership between decentralized and non-decentralized identities. + +--- + +## 内容 + +
+ +
+ +--- + +## 脚本 + +
+ + Expand for the full script + +0:00\ +DIDs, or decentralized identifiers, provide a way to identify users or organizations in a decentralized way. DIDs can be used as account identifiers. + +0:20 +For example, someone using a specific service would create a DID associated with that service that they control. They could use this DID to authorize access to the service, and manage assets the service may provide and permissions it may request. + +0:40 +In non-decentralized environments, the account information is controlled and owned by the service provider. With decentralized identities, the identity and the data associated with it, are controlled and owned by the user. This allows the user to use the DID with many different services and in many different contexts, and control the information associated with it. + +
+ +--- + +## 常见问题 + +- **DIDs are NFTs:** DIDs are actually a special type of NFT. This ensures uniqueness and that only one entitiy has control of any one DID. +- **DID limits:** A user can generate many DIDs and associate each one with different services or assets. + +--- + +## 知识检测 + +:::tip Question 1 - DID issuance + +True or False; A DID is issued by a service provider to identify a user. + +::: + +
+ + Answer (expand when ready to see the answer) + +错误 The DID is created by the user, and associated with a service provider. This allows the user to use one DID for many different services. + +
+ +:::tip Question 2 - DID limits + +How many DIDs can a user have? + +::: + +
+ + Answer (expand when ready to see the answer) + +There is no practical limit to the number of DIDs a user can create. + +
+ +--- + +## 附加资源 + +### 链接 + +- More about [primitives](https://docs.chia.net/guides/primitives/): guides for each primitive, and how to use them. +- In depth [DID guide](https://docs.chia.net/guides/nft-intro/): how to create a DID. +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 +- Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-nft.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-nft.md new file mode 100644 index 0000000000..3cd89c5cbc --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-nft.md @@ -0,0 +1,114 @@ +--- +title: NFTs +slug: /academy-nft +--- + +In this lesson, we talk about what an NFT is, and some examples of how it can be used. + +## 学习目标 + +- **Fungibility**: Understand what makes something fungible. +- **Uses and Value**: Understand the use of NFTs, and what makes something valuable. + +--- + +## 内容 + +
+ +
+ +--- + +## 脚本 + +
+ + Expand for the full script + +0:00\ +NFTs, or non-fungible tokens, can be used to provide proof of ownership, handle licenses and royalties, and ensure uniqueness for digital entities and even real-world items. + +0:20 +Let's start at the basics. An item is non-fungible if it can not be interchanged for another identical item. For example, an original painting, a driver's license, or even a family heirloom. These items are unique and can't be substituted for something of "equal value" since any other item would not have the same properties. + +0:40 +Since digital items can be inherently duplicated, we need to pair the item with something that isn't. An NFT is a token on the blockchain that represents an item. This item could be physical and the NFT is a sort of registry of ownership on the blockchain, or the item could be digital, with the NFT serving as the non-interchangeable component. + +1:00 +NFTs can be used to provide ownership provenance, such as the sale and resale of digital art. They can also provide a mechanism of distributing royalties to the original author upon resale. + +1:20 +NFTs can also provide a method of verifying and transferring more ethereal concepts such as digital memberships and ecosystem specific assets. +It's an important point that just because something is non-fungible, it is not inherently valuable. For example, a family heirloom is non-fungible, and may have emotional value to one person, + +1:40 +but it does not have true value outside of a specific context. NFTs are a tool that is useful for providing a new way to work with digital items. They do not themselves create value. + +
+ +--- + +## 常见问题 + +- **Size Limitations:** Because there is a limit to how large a single transaction can be, it is very rare to have the digital item itself embedded in the NFT. The token will instead contain a reference to the item that is hosted elsewhere. +- **NFTs are Data:** It is common to think of some type of image or art when thinking of NFTs. This is a very limited view. NFTs are essentially data objects that can contain references to other digital assets, or simply be the data object itself. The referenced asset may be a piece of digital art, but it could just as easily be a document, contract, application, etc. + +--- + +## 知识检测 + +:::tip Question 1 - Fungibility + +What makes something fungible? + +::: + +
+ + Answer (expand when ready to see the answer) + +Something is fungibile if it can be easily substituted for another item. + +
+ +:::tip Question 2 - Physical vs. Digital + +True or False; An NFT can really only represent digital assets. + +::: + +
+ + Answer (expand when ready to see the answer) + +错误 An NFT can also represent physical assets, and serves as a registry on the blockchain. + +
+ +:::tip Question 3 - Value + +True or False; Minting and NFT makes the underlying asset valuable. + +::: + +
+ + Answer (expand when ready to see the answer) + +错误 Simply being an NFT does not make it valuable. NFTs are a tool to handle digital assets in a new way. + +
+ +--- + +## 附加资源 + +### 链接 + +- More about [primitives](https://docs.chia.net/guides/primitives/): guides for each primitive, and how to use them. +- In depth [NFT guide](https://docs.chia.net/guides/nft-intro/): how to mint an NFT. +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 +- Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-offers.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-offers.md new file mode 100644 index 0000000000..8b5832bb0a --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/academy-offers.md @@ -0,0 +1,98 @@ +--- +title: Offers +slug: /academy-offers +--- + +In this lesson, we talk about Chia Offers and how they enables safe peer-to-peer trading. + +## 学习目标 + +- **Peer-to-peer trading**: Understand what offers are and how they enable P2P trading. +- **Managing offer files**: Learn how to share, accept, and cancel offers. + +--- + +## 内容 + +
+ +
+ +--- + +## 脚本 + +
+ + Expand for the full script + +0:00 +Chia Offers are used to trade assets between two parties safely and securely in a direct, peer-to-peer transaction. They can be used to trade any combination of assets including XCH, CATs, and NFTs. + +0:20 +When an offer is accepted, the trade happens atomically, meaning the entirety of the trade settles simultaneously with no counterparty risk. The creator of an offer specifies the assets they wish to offer as well as the assets they wish to receive. + +0:40 +An offer file is then created, represented as a string of characters containing an incomplete and partially signed spend bundle. The creator can then share this offer file through any means, such as email, QR code, and offer file exchange services. Anyone that sees an offer file and wants to accept the trade can do so by signing and completing the other side of the spend bundle and submit it to the blockchain to be settled atomically. + +1:00 +Assets with smart contracts attached such as NFTs that include creator royalties are also enforced. If a creator wishes to cancel an existing offer, they can simply spend any of the assets offered to invalidate it. + +1:20 +Offers can also be set to automatically expire after a certain amount of time if nobody takes it. Offer files allow for true peer-to-peer transactions, introducing a new way to create safe and decentralized liquid markets for assets on the Chia blockchain. + +
+ +--- + +## 常见问题 + +- **Locked coins:** Some wallets including the GUI Reference Wallet will indicate part of the balance of an asset as "locked" or "unspendable" if an Offer was created offering that asset. In truth, those coins aren't actually unspendable but if they _are_ spent, any offer(s) that use those coins will be invalid. In order to not lock up more than the offered amount, one can split their coins into smaller amounts prior to creating an offer. +- **Canceling open offers:** If an offer has been previously shared (e.g. uploaded to dexie) and the creator wishes to cancel it, they need to cancel with the "Cancel on blockchain" function enabled to ensure the offer is truly invalidated and not just deleted locally. +- **Blockchain fees:** Accepting an offer is an on-chain transaction and hence requires a transaction fee to be prioritized when blocks are full. The creator can embed fees as part of the offer file but the buyer can also optionally include a transaction fee as well. + +--- + +## 知识检测 + +:::tip Question 1 - Supported assets + +True or False; An offer file is only for trading NFTs. + +::: + +
+ + Answer (expand when ready to see the answer) + +错误 An offer file can be used to trade any combination of assets including (but not limited to) XCH, CATs, and NFTs. Offer files can also be used with other types of coins such as Verifiable Credentials or DataLayer singletons. + +
+ +:::tip Question 2 - NFT Royalties + +True or False; When creating an offer for NFTs, creator royalties (if any) must be included. + +::: + +
+ + Answer (expand when ready to see the answer) + +True. If an NFT specifies a creator royalty, this amount must be included as part of the requested assets to be considered valid. Royalties are applied to XCH and CATs that are a part of the offer. Wallets will automatically calculate and include these coins to be sent to the NFT creator. + +
+ +--- + +## 附加资源 + +### 链接 + +- More about [primitives](https://docs.chia.net/guides/primitives/): guides for each primitive, and how to use them. +- CLI [Guide](https://docs.chia.net/guides/crash-course/cats-offers-nfts/#offers): documentation on how to interact with offers with the CLI. +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 +- Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. +- Offer file [exchanges](https://dexie.space): a bulletin board system for sharing and discovering offer files. + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/primitives-overview.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/primitives-overview.md new file mode 100644 index 0000000000..9b003c1615 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/primitives/primitives-overview.md @@ -0,0 +1,106 @@ +--- +title: Primitives Overview +slug: /primitives-overview +--- + +In this lesson, we talk about what a primitive is, and how it can be used. + +## 学习目标 + +- **Primitives**: Recognize the basic Chia primitives. +- **Open-Source**: Understand how open-source improves Chia through community involvement. + +--- + +## 内容 + +
+ +
+ +--- + +## 脚本 + +
+ + Expand for the full script + +0:00\ +Primitives are what we call commonly used structures in Chialisp. They are essentially features that are specifically supported with native methods in our various libraries, and have defined structures to ensure compatibility. + +0:20 +These Primitives include features commonly found in other blockchains such as NFTs and DIDs, but also include unique features such as CATs, Offers, Clawback, and Verifiable Credentials. +These primitives are the building blocks to creating efficient blockchain powered applications. + +0:40 +Each primitive represents a Chialisp puzzle that adheres to the current standard for that feature. These standards are submitted and can be modified by the community through the CHIP process, whereby new features, or modifications to existing primitives can be submitted and reviewed by community members, in keeping with the open-source nature of the Chia Blockchain. + +1:00 +Many of our unique primitives have come out of this process and it ensures that as development matures, the blockchain will evolve to satisfy the needs of developers in a multitude of use-cases. + +
+ +--- + +## 常见问题 + +- **Primitives as Standards:** Primitives are pre-defined features that adhere to certain standards agreed upon by the community. That does not mean that custom bespoke features cannot be developed or used for a specific use-case, even if it is not widely used. Chialisp allows any developer to create custom puzzles that map to their specific use-case, if an existing primitive does not quite fit. + +--- + +## 知识检测 + +:::tip Question 1 - Features + +True or False; Primitives are standardized features of the Chia Blockchain. + +::: + +
+ + Answer (expand when ready to see the answer) + +True. Primitives are what we call features that have defined standards, as agreed upon by the community. + +
+ +:::tip Question 2 - CHIPs? + +What does CHIP stand for? + +::: + +
+ + Answer (expand when ready to see the answer) + +CHIP stands for CHia Improvement Proposal. It is a way for the community of developers to propose new features, or changes to existing features. + +
+ +:::tip Question 3 - Custom Features + +True or False; Developers should only use pre-defined primitives. + +::: + +
+ + Answer (expand when ready to see the answer) + +错误 Primitives are meant to provide common and useful building blocks that are flexible to cover many use-cases. However, there may be instances where the existing primitives don't provide the needed functionality and a custom puzzle will be needed. + +
+ +--- + +## 附加资源 + +### 链接 + +- More about [primitives](https://docs.chia.net/guides/primitives/): guides for each primitive, and how to use them. +- Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 +- Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/harvesters.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/harvesters.md index 419cd25cd3..88cbdca06d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/harvesters.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/harvesters.md @@ -16,7 +16,7 @@ slug: /harvester-architecture 就大多数挑战而言，质量 ( 步骤1) 很低，所以没有必要获取全部证明（步骤2）。 一个节点有28秒的时间返回一个证明，所以磁盘I/O 不会是一个限制因素， 即使证明存储在慢速HDD上。 -:::note +:::注意： 磁带驱动器太慢无法耕种。 The protocol was designed to support hard disks, but nothing slower. It is possible to use tape for long-term plot storage, only transferring the plots to disks for occasional farming, but this is likely a very rare use case. ::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/mempool.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/mempool.md index ae026edc4d..74853dcd98 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/mempool.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/mempool.md @@ -7,6 +7,8 @@ The mempool (or memory pool) is a collection of transactions stored by full node The mempool is a required facet of Chia due to the decentralized nature of the blockchain. Transaction blocks occur approximately every 52 seconds, and it's impossible to predict who will win a block. Therefore, all transactions must be broadcast to the whole network and stored locally until they are confirmed. Additionally, it is normal to have more pending transactions than can fit in a single block, so the mempool also acts as a queue for inclusion into the blockchain. +For more information about the mempool, see our [blog post](https://www.chia.net/2024/01/11/getting-to-know-the-mempool-and-transaction-fees/) on this subject. + :::info How many transactions can fit into a block? Due to the varying size of transactions, and the different definitions of what even counts as a "transaction," there is not an exact number. But just for a bit of rough guidance, approximately 1000 transactions with two inputs and two outputs, or 2000 transactions with one input and one output can fit into a single block. ::: @@ -27,52 +29,60 @@ To view the current status of the mempool, see the dashboard for [mainnet](https :::info -Currently, the block size is artificially limited to 50% of its capacity. Eventually this limitation will be lifted, but the numbers discussed in this section assume it is being enforced. - -::: - -:::info - -The total size of the mempool differs by network. - -- Mainnet: 550 billion cost, or 100 blocks -- Testnet10: 110 billion cost, or 20 blocks +- By default, the total size of the mempool is 20 blocks. This true for both mainnet and testnet11. +- Prior to version 2.2, the block size was artificially capped at 50% of its capacity. +- Starting in version 2.2, the block size cap was increased to 60%. +- This limitation will be increased gradually, until it reaches 100%, or 11 billion cost -- the limit enforced by the consensus rules. +- The size (in CLVM cost) of the mempool is `mempool blocks * max cost per block * block size limit`. + - In version 2.2, this amounts to `20 * 11 billion * 0.6`, which equals 132 billion. + - When the block limiter is lifted, the total size will be `20 * 11 billion`, or 220 billion. ::: ### Scenario 1: Mempool Not Busy -If the transaction you just submitted -- plus the entire contents of the mempool -- can fit into one block, then your transaction will be added to the next block. This is true even if you don't include a transaction fee. +If the transaction you just submitted -- plus the entire contents of the mempool -- can fit into one block, then your transaction will be added to the next block. This is true even if you don't include a transaction fee. This is true even if you don't include a transaction fee. -The reason for this is straightforward -- the farmer has nothing to gain by excluding certain transactions, so it will include everything. Note that some proprietary software takes the opposite approach: the farmer will _only_ include transactions that pay a fee, regardless of mempool size. +The reason for this is straightforward -- the farmer has nothing to gain by excluding certain transactions, so it will include everything. The reason for this is straightforward -- the farmer has nothing to gain by excluding certain transactions, so it will include everything. Note that some proprietary software takes the opposite approach: the farmer will _only_ include transactions that pay a fee, regardless of mempool size. The mempool for Chia's mainnet is often in this state. This does not mean that no transactions are being submitted. It simply means that the network's speed of around 20 transactions per second is sufficient to keep up with demand. ### Scenario 2: Mempool Busy But Not Full -If the mempool's contents will occupy more than one block, but the mempool is not full, then it is considered _busy_. In this case: +If the mempool's contents will occupy more than one block, but the mempool is not full, then it is considered _busy_. In this case: In this case: -- Transactions that don't include fees will be added to the mempool, but they won't make it into the next block. Instead, they will have to "wait in line" for higher-priority transactions to be cleared. They likely will eventually be included in a block, but this is not guaranteed. -- Transactions with fees will be added to the mempool and prioritized according to the size of their fee-per-cost. For example, a transaction with a 1-mojo fee will enter the queue ahead of zero-fee transactions. +- Transactions that don't include fees will be added to the mempool, but they won't make it into the next block. Instead, they will have to "wait in line" for higher-priority transactions to be cleared. They likely will eventually be included in a block, but this is not guaranteed. Instead, they will have to "wait in line" for higher-priority transactions to be cleared. They likely will eventually be included in a block, but this is not guaranteed. +- Transactions with fees will be added to the mempool and prioritized according to the size of their fee-per-cost. Transactions with fees will be added to the mempool and prioritized according to the size of their fee-per-cost. For example, a transaction with a 1-mojo fee will enter the queue ahead of zero-fee transactions. :::info Testnet10 info -Testnet10 is constantly being "dusted" (thousands of small transactions are being included) in order to simulate a busy network, which can be useful for testing. The dust transactions do not include any fees, so in order for your transaction to be prioritized ahead of the dust, you simply have to include a 1-mojo fee. In this case, your transaction will likely be included in the next transaction block. However, if you don't include a fee, it will likely need to wait ~40-60 minutes before being included. +Testnet10 is constantly being "dusted" (thousands of small transactions are being included) in order to simulate a busy network, which can be useful for testing. The dust transactions do not include any fees, so in order for your transaction to be prioritized ahead of the dust, you simply have to include a 1-mojo fee. In this case, your transaction will likely be included in the next transaction block. However, if you don't include a fee, it will likely need to wait ~40-60 minutes before being included. The dust transactions do not include any fees, so in order for your transaction to be prioritized ahead of the dust, you simply have to include a 1-mojo fee. In this case, your transaction will likely be included in the next transaction block. However, if you don't include a fee, it will likely need to wait ~40-60 minutes before being included. ::: ### Scenario 3: Mempool Full -If the mempool is completely full, then in order for your transaction to be added, it will need to kick out one or more transactions. In this scenario: +If the mempool is completely full, then in order for your transaction to be added, it will need to kick out one or more transactions. In this scenario: In this scenario: - Transactions with no fee will not be added to the mempool. - Transactions with a fee of less than five mojos per cost (~100 million mojos for 2-input, 2-output transactions) will be treated as zero-fee transactions, i.e. they will not be added to the mempool. - Transactions with a fee of at least five mojos per cost will be added to the mempool, prioritized by fee-per-cost, _if_ they are not the lowest priority transactions. In this case, one or more of the lowest-priority transactions will be removed. -- If the lowest-cost transaction in the mempool is higher than than the new transaction, then the new transaction will not be added. For example, if the lowest priority transaction in the mempool has a fee of 100 mojos-per-cost (as might be the case in a very busy network), then a new transaction will have to include a higher fee in order to be added to the mempool. -This scenario often occurs on testnet10. When the mempool is completely full, the dusters stop submitting transactions until some of the dust has been cleared. This scenario might occasionally happen on mainnet as well, in which case a minimum fee would be required. +This scenario often occurs on testnet11. This scenario often occurs on testnet10. When the mempool is completely full, the dusters stop submitting transactions until some of the dust has been cleared. This scenario might occasionally happen on mainnet as well, in which case a minimum fee would be required. This scenario might occasionally happen on mainnet as well, in which case a minimum fee would be required. + +If you see `INVALID_FEE_TOO_CLOSE_TO_ZERO` in your log file, the mempool was likely full when you submitted your transaction, and you did not include a sufficient fee to kick out an existing transaction. Try resubmitting your transaction with a higher fee. Try resubmitting your transaction with a higher fee. -If you see `INVALID_FEE_TOO_CLOSE_TO_ZERO` in your log file, the mempool was likely full when you submitted your transaction, and you did not include a sufficient fee to kick out an existing transaction. Try resubmitting your transaction with a higher fee. +### Scenario 4: Mempool Full of Transactions with Fees + +This is the final scenario, where every transaction in the mempool has a fee of at least five mojos per cost. In order for your transaction to be added, it will need to kick out one or more transactions. In this scenario: + +- Transactions with no fee will not be added to the mempool. +- Transactions with a fee of less than five mojos per cost (~100 million mojos for 2-input, 2-output transactions) will be treated as zero-fee transactions, i.e. they will not be added to the mempool. +- Transactions with a fee of at least five mojos per cost _might_ be added to mempool. For this to happen, they will need to kick out one or more transactions with a lower fee-per-cost ratio. For example: + - If the "cheapest" transaction currently in the mempool has a fee per cost of 10, and your transaction's fee per cost is 9, then your transaction will not be added to the mempool. + - If the "cheapest" transaction is 10, and yours is 15, then it likely will be added. However, even in this case, there are scenarios where your transaction might not be added, such as when the lowest-cost transaction currently in the mempool is quite large. + +If the mempool from Chia's mainnet reaches this state, the competition for block space will be strong. In order for your transaction to be included, the minimum fee might be significantly higher than it would be in the other scenarios. ## Replace by Fee @@ -80,6 +90,15 @@ A transaction can replace another transaction in the mempool if it spends at lea For example, if the original transaction spent coins A and B, then another transaction that spends A, B, and C can replace it. However, a transaction that spends B and C cannot. This prevents denial-of-service (DOS) attacks, as well as censorship of transactions. There is also a minimum fee bump which might depend on mempool software being used. In `chia-blockchain`, this is set to 5 fee-per-cost. This prevents spam replacement transactions. +The full conditions for replace by fee are: + +1. The new spend bundle needs to include at least all the spends in the original one (can include additional spends) +2. The new spend bundle needs to pay a higher fee per cost than the original one (and higher than the [minimum fee required for inclusion](https://docs.chia.net/mempool/#fee-required-for-inclusion)) +3. The new spend bundle needs to pay at least 10000000 mojos more in fees than the original one +4. If there were any time-locks associated with the original spend, the new spend bundle has to have the same time-lock + +The replace by fee logic can be found [here](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool_manager.py#L678)in the codebase) + ## Block Creation When the farmer makes a block, they will select the highest fee-per-cost transactions from the mempool until they reach the maximum block size. These spend bundles are combined into one large spend bundle, which is guaranteed to be valid, since all spend bundles in the mempool must spend disjointed coins. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/timelords.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/timelords.md index 5504a9a87b..d48ae1f0cc 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/timelords.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/architecture/timelords.md @@ -27,7 +27,7 @@ You can learn about potential attacks against Chia's network in the [Attacks and There are two primary types of Timelords: Regular and Blueboxes. -The first is the core Timelord that takes in Proofs of Space and uses a single fastest core to perform repeated squaring in a [class group of unknown order](https://github.com/Chia-Network/vdf-competition/blob/master/classgroups.pdf) as fast as possible. Beside each running VDF (referred to as a vdf_client in the application and source) is a set of proof generation threads that accumulate the proof that the time calculation's number of iterations was done correctly. +The first is the core Timelord and can be either a software Timelord or a hardware Timelord (ASIC) that takes in Proofs of Space and uses a single fastest core to perform repeated squaring in a [class group of unknown order](https://github.com/Chia-Network/vdf-competition/blob/master/classgroups.pdf) as fast as possible. Beside each running VDF (referred to as a vdf_client in the application and source) is a set of proof generation threads that accumulate the proof that the time calculation's number of iterations was done correctly. The second are Bluebox Timelords. Blueboxes are most any machine - especially things like old servers or gaming machines - that scour the historical chain looking for uncompressed proofs of time. So that the chain moves quickly, the regular Timelords use a faster method of generating proofs of time but the proofs are larger, which takes your Raspberry Pi a lot more time and effort to validate and sync the blockchain. A Bluebox picks up an uncompressed Proof of Time and recreates it, but this time with the slower and more compact proofs generated at the end. Those are then gossiped around to everyone so they can replace the large and slow to verify Proofs of Time with the compact and much quicker to validate version of exactly the same thing. @@ -39,38 +39,19 @@ It's good to have a few Timelords out there. There can be things like routing fl The Company plans to run a few Timelords around the world - and some backups too - to ensure that all Farmers and nodes can hear the beat that the Timelords are calling. -## Installing a Timelord +For installation and usage documentation please refer [here](/timelord-install). -:::info -If you want to run a Timelord on Linux/MacOS, first follow the Install from Source instructions [here](/installation#from-source). Then run: - -```bash -. ./activate -sh install-timelord.sh -chia start timelord & -``` - -::: - -Timelords execute sequential verifiable delay functions (proofs of time or VDFs), that get added to blocks to make them valid. This requires fast CPUs and a few cores per VDF. - -Due to restrictions on how [MSVC](https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B) handles 128 bit numbers and how Python relies upon MSVC, it is not possible to build and run Timelords of all types on Windows. - -### Regular Timelords - -On MacOS x86_64 and all Linux distributions, building a Timelord is as easy as running `chia start timelord &` in the virtual environment. You can also run `./vdf_bench square_asm 400000` once you've built Timelord to give you a sense of your optimal and unloaded ips. Each run of `vdf_bench` can be surprisingly variable and, in production, the actual ips you will obtain will usually be about 20% lower due to load of creating proofs. The default configuration for Timelords is good enough to just let you start it up. Set your log level to INFO and then grep for "Estimated IPS:" to get a sense of what actual ips your Timelord is achieving. - -### Bluebox Timelords +## Troubleshooting a Timelord -Once you build the Timelord with `sh install-timelord.sh` in the virtual environment, you will need to make two changes to `~/.chia/VERSION/config.yaml`. In the `timelord:` section, set `bluebox_mode:` to `True`. Then you need to proceed to the `full_node:` section and set `send_uncompact_interval:` to something greater than 0. We recommend `300` seconds there so that your Bluebox has some time to prove through a lot of the un-compacted Proofs of Time before the node drops more into its lap. The default settings may otherwise work but if the total effort is a little too much for whatever machine you are on you can also lower the `process_count:` from 3 to 2, or even 1, in the `timelord_launcher:` section. You know it is working if you see `VDF Client: Sent proof` in your logs at INFO level. +For troubleshooting steps please refer to the documentation [here](/troubleshooting/timelords). ## The Future of Timelords -In 2023, CNI received its first batch of ASIC timelords. When run as a cluster of three VDFs, these timelords could hit upwards of one million IPS. This was approximately four times the speed of the fastest non-ASIC timelords. After installing several timelords in strategic locations globally, and after thorough testing on private testnets, the company added the ASICs to the biggest public testnet -- testnet10. Finally, after [years of designing](https://www.businesswire.com/news/home/20211013005324/en/Chia-Partners-With-Supranational-to-Create-Industry-Leading-Proof-of-Space-Time-Security) the ASICs and months of testing them, they were activated on mainnet in October 2023. +In 2023, CNI received its first batch of ASIC timelords. When run as a cluster of three VDFs, these timelords could hit upwards of one million IPS. This was approximately four times the speed of the fastest non-ASIC timelords. After installing several timelords in strategic locations globally, and after thorough testing on private testnets, the company added the ASICs to a public testnet. Finally, after [years of designing](https://www.businesswire.com/news/home/20211013005324/en/Chia-Partners-With-Supranational-to-Create-Industry-Leading-Proof-of-Space-Time-Security) the ASICs and months of testing them, they were activated on mainnet in October 2023. -The next step is to distribute some of the remaining ASIC timelords to a select list of applicants, as detailed in a [blog post](https://www.chia.net/2023/10/26/asic-timelords-faster-than-fast-chia-network/). This process will ensure a high amount of global redundancy on this critical network infrastructure. +The next step was to distribute some of the remaining ASIC timelords to a select list of applicants, as detailed in a [blog post](https://www.chia.net/2023/10/26/asic-timelords-faster-than-fast-chia-network/). This process ensures a high amount of global redundancy on this critical network infrastructure. -Of course, as technology improves, the ASIC design will need to be updated. However, this process is extremely costly, and the current generation is already pushing upon the limits imposed by the laws of physics. We expect the current crop to remain the fastest timelords in the world for years to come. +Of course, as technology improves, the ASIC design will need to be updated. However, this process is extremely costly, and the current generation is already pushing upon the limits imposed by the laws of physics. We expect the current crop to remain the fastest timelords in the world for years to come. However, this process is extremely costly, and the current generation is already pushing upon the limits imposed by the laws of physics. We expect the current crop to remain the fastest timelords in the world for years to come. ## Timelords and Attacks diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/block-validation/block-format.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/block-validation/block-format.md index 1d01d5dcef..7d2e5509c1 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/block-validation/block-format.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/block-validation/block-format.md @@ -19,7 +19,7 @@ slug: /block-format - **foliage**: Foliage: Foliage data for the reward chain block, the hash of this is the `header_hash`. - **foliage_transaction_block**: Optional[FoliageTransactionBlock]: Transaction related metadata that is relevant for light clients (not actual transactions), only for tx blocks. - **transactions_info**: Optional[TransactionsInfo]: Transaction related metadata that is not relevant for light clients (not actual transactions), only for tx blocks. -- **transactions_generator**: Optional[SerializedProgram]: A clvm program that generates all transactions (spends). +- **transactions_generator**: Optional[SerializedProgram]: A clvm program that generates all transactions (spends). See the next section for an important [update](#transactions_generator-update) due to the 2.1.0 hard fork. - **transactions_generator_ref_list**: List[uint32]: A list of block heights of previous generators referenced by this block's generator. ## transactions_generator update diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/block-validation/block-rewards.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/block-validation/block-rewards.md index 5418957a8c..5b0bdd8932 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/block-validation/block-rewards.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/block-validation/block-rewards.md @@ -7,7 +7,7 @@ In Chia, the issuance schedule, also referred to as the block reward schedule, d ## Strategic Reserve (pre-farm) -The first block of the network pays out 21 million XCH, divided into a 1/8 coin and a 7/8 coin, to an address that Chia Network Inc controls. The purpose and future usage of the funds is described in the [business whitepaper](https://www.chia.net/whitepaper). +The first block of the network pays out 21 million XCH, divided into a 1/8 coin and a 7/8 coin, to an address that Chia Network Inc controls. The purpose and future usage of the funds is described in the [business white paper](https://www.chia.net/whitepaper). ## Halvings @@ -36,7 +36,7 @@ Therefore, Chia coins are never destroyed. In a given block, any portion of a sp ## Farmer vs Pool reward -The block reward is divided into two coins. The first coin goes to the farmer puzzle hash, which is specified by the farmer, and usually goes straight to the farmer's wallet. This contains 1/8 of the total value (0.25 XCH for the first 3 years). This is referred to as the _farmer coin_. +The block reward is divided into two coins. The first coin goes to the farmer puzzle hash, which is specified by the farmer, and usually goes straight to the farmer's wallet. This contains 1/8 of the total value. This is referred to as the _farmer coin_. The second coin, with 7/8 of the value, is called the _pool coin_. This coin can go to one of two places: @@ -55,4 +55,4 @@ As detailed in the [Business white paper](https://www.chia.net/whitepaper), the | 10 - 12 | `20 183 040` | March 2033 | 0.25 XCH | 0.21875 XCH | 0.03125 XCH | | 13 - ∞ | ∞ | ∞ | 0.125 XCH | 0.109375 XCH | 0.015625 XCH | -Note that the rewards are adjusted according to a block height, not a timestamp. The `Final Block` column is therefore accurate as the last block before the rewards are modified. The months and years are only estimates based on when the block heights are likely to be reached. +Note that the rewards are adjusted according to a block height, not a timestamp. Note that the rewards are adjusted according to a block height, not a timestamp. The `Final Block` column is therefore accurate as the last block before the rewards are modified. The months and years are only estimates based on when the block heights are likely to be reached. The months and years are only estimates based on when the block heights are likely to be reached. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/asic-hwvdf.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/asic-hwvdf.md new file mode 100644 index 0000000000..ea897999ee --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/asic-hwvdf.md @@ -0,0 +1,119 @@ +--- +sidebar_label: ASICs +title: ASICs HW VDF +slug: /asic-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +## Reference + +### `hw_vdf_client` + +Functionality: Run the ASIC HW VDF Software + +Usage: hw_vdf_client [OPTIONS] PORT [N_VDFS] + +Options: + +| Long Command | Type | Required | Description | +| :----------------- | :------ | :------- | :---------------------------------------------------- | +| --freq | INTEGER | False | set ASIC frequency [%d, 200 - 2200] | +| --voltage | INTEGER | False | set board voltage [.88, 0.7 - 1.0] | +| --ip | TEXT | False | timelord IP address [localhost] | +| --vdfs-mask | TEXT | False | mask for enabling VDF engines [7, 1 - 7] | +| --vdf-threads | TEXT | False | number of software threads per VDF engine [4, 2 - 64] | +| --proof-threads | TEXT | False | number of proof threads per VDF engine [3, 1 - 63] | +| --auto-freq-period | TEXT | False | auto-adjust frequency every N seconds [0, 10 - inf] | +| --list | TEXT | False | list available devices and exit | +| --help | None | False | Show a help message and exit | + +
+Example 1 - Run the ASIC software with defaults + +```bash +hw_vdf_client 8000 3 +``` + +Response: + +``` +2024-04-12T10:32:05.898 Setting frequency to 1100.000000 MHz +2024-04-12T10:32:06.016 Frequency is 1100.000000 MHz +2024-04-12T10:32:06.020 Board voltage is 0.875 V +2024-04-12T10:32:06.020 Setting voltage to 0.880 V +2024-04-12T10:32:06.021 Board voltage is now 0.875 V +2024-04-12T10:32:06.032 Board current is 0.698 A +2024-04-12T10:32:06.043 Board power is 0.610 W +2024-04-12T10:32:06.049 Connecting to 127.0.0.1:8000 +2024-04-12T10:32:06.049 VDF 0: Connected to timelord, waiting for challenge +``` + +
+ +
+Example 2 - Run the ASIC software with auto-frequency, initial frequency, and defined ip + +```bash +hw_vdf_client --freq 1500 --auto-freq 60 --ip 192.168.0.122 8000 3 +``` + +Response: + +``` +2024-04-12T10:32:05.898 Setting frequency to 1500.000000 MHz +2024-04-12T10:32:06.016 Frequency is 1500.000000 MHz +2024-04-12T10:32:06.020 Board voltage is 0.875 V +2024-04-12T10:32:06.020 Setting voltage to 0.880 V +2024-04-12T10:32:06.021 Board voltage is now 0.875 V +2024-04-12T10:32:06.032 Board current is 0.698 A +2024-04-12T10:32:06.043 Board power is 0.610 W +2024-04-12T10:32:06.049 Connecting to 192.168.0.122:8000 +2024-04-12T10:32:06.049 VDF 0: Connected to timelord, waiting for challenge +``` + +
+ +
+Example 3 - Run the ASIC software with defined ip and only 1 vdf (i.e. defaults for cluster) + +```bash +hw_vdf_client --ip 192.168.0.122 8000 1 +``` + +Response: + +``` +2024-04-12T10:32:05.898 Setting frequency to 1100.000000 MHz +2024-04-12T10:32:06.016 Frequency is 1100.000000 MHz +2024-04-12T10:32:06.020 Board voltage is 0.875 V +2024-04-12T10:32:06.020 Setting voltage to 0.880 V +2024-04-12T10:32:06.021 Board voltage is now 0.875 V +2024-04-12T10:32:06.032 Board current is 0.698 A +2024-04-12T10:32:06.043 Board power is 0.610 W +2024-04-12T10:32:06.049 Connecting to 192.168.0.122:8000 +2024-04-12T10:32:06.049 VDF 0: Connected to timelord, waiting for challenge +``` + +
+ +--- + +## Troubleshooting a Timelord + +For troubleshooting steps please refer to the documentation [here](/troubleshooting/timelords). + +--- + +## Timelord support + +Join Our [Discord](https://discord.gg/chia) and jump into the #support channel for support + +--- + +## Timelord FAQ + +For FAQ please refer to the documentation [here](/timelord-install#timelord-faq). + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/cat-admin.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/cat-admin.md index 5e2194b162..acb336d582 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/cat-admin.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/cat-admin.md @@ -23,27 +23,27 @@ Usage: cats [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| -l | --tail | TEXT | True | The TAIL program to launch this CAT with | -| -c | --curry | TEXT | False | An argument to curry into the TAIL | -| -s | --solution | TEXT | False | The solution to the TAIL program [default: ()] | -| -t | --send-to | TEXT | True | The address these CATs will appear at once they are issued | -| -a | --amount | INTEGER | True | The amount to issue in mojos (regular XCH will be used to fund this) | -| -m | --fee | INTEGER | False | The fees for the transaction, in mojos [default: 0] | -| -d | --authorized-provider | TEXT | False | A trusted DID that can issue VCs that are allowed to trade the CAT. Specifying this option will make the CAT a CR (credential restricted) CAT. Requires specifying either `--proofs-checker` or `--cr-flag` | -| -r | --proofs-checker | TEXT | False | The program that checks the proofs of a VC for a CR-CAT. Specifying this option requires a value for `--authorized-providers` | -| -v | --cr-flag | TEXT | False | Specify a list of flags to check a VC for in order to authorize this CR-CAT. Specifying this option requires a value for `--authorized-providers`. Cannot be used if a custom `--proofs-checker` is specified. | -| -f | --fingerprint | INTEGER | False | The wallet fingerprint to use as funds | -| -sig | --signature | TEXT | False | A signature to aggregate with the transaction | -| -as | --spend | TEXT | False | An additional spend to aggregate with the transaction | -| -b | --as-bytes | None | False | Output the spend bundle as a sequence of bytes instead of JSON | -| -sc | --select-coin | None | False | Stop the process once a coin from the wallet has been selected and return the coin | -| -q | --quiet | None | False | Quiet mode will not ask to push transaction to the network | -| -p | --push | None | False | Automatically push transaction to the network in quiet mode | -| | --root-path | PATH | False | The root folder where the config lies [default: ~/.chia/mainnet] | -| | --wallet-rpc-port | INTEGER | False | The RPC port the wallet service is running on | -| | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -l | --tail | TEXT | True | The TAIL program to launch this CAT with | +| -c | --curry | TEXT | False | An argument to curry into the TAIL | +| -s | --solution | TEXT | False | The solution to the TAIL program [default: ()] | +| -t | --send-to | TEXT | True | The address these CATs will appear at once they are issued | +| -a | --amount | INTEGER | True | The amount to issue in mojos (regular XCH will be used to fund this) | +| -m | --fee | INTEGER | False | The fees for the transaction, in mojos [default: 0] | +| -d | --authorized-provider | TEXT | False | A trusted DID that can issue VCs that are allowed to trade the CAT. Specifying this option will make the CAT a CR (credential restricted) CAT. Requires specifying either `--proofs-checker` or `--cr-flag` Specifying this option will make the CAT a CR (credential restricted) CAT. Requires specifying either `--proofs-checker` or `--cr-flag` | +| -r | --proofs-checker | TEXT | False | The program that checks the proofs of a VC for a CR-CAT. Specifying this option requires a value for `--authorized-providers` Specifying this option requires a value for `--authorized-providers` | +| -v | --cr-flag | TEXT | False | Specify a list of flags to check a VC for in order to authorize this CR-CAT. Specifying this option requires a value for `--authorized-providers`. Cannot be used if a custom `--proofs-checker` is specified. Specifying this option requires a value for `--authorized-providers`. Cannot be used if a custom `--proofs-checker` is specified. | +| -f | --fingerprint | INTEGER | False | The wallet fingerprint to use as funds | +| -sig | --signature | TEXT | False | A signature to aggregate with the transaction | +| -as | --spend | TEXT | False | An additional spend to aggregate with the transaction | +| -b | --as-bytes | None | False | Output the spend bundle as a sequence of bytes instead of JSON | +| -sc | --select-coin | None | False | Stop the process once a coin from the wallet has been selected and return the coin | +| -q | --quiet | None | False | Quiet mode will not ask to push transaction to the network | +| -p | --push | None | False | Automatically push transaction to the network in quiet mode | +| | --root-path | PATH | False | The root folder where the config lies [default: ~/.chia/mainnet] | +| | --wallet-rpc-port | INTEGER | False | The RPC port the wallet service is running on | +| | --help | None | False | Show a help message and exit |
Example 1 - select a coin from the wallet with a value of at least 1 XCH (1 trillion mojos) @@ -94,7 +94,7 @@ After pushing the transaction, the new ID and Eve Coin (singleton parent coin) w
Example 3 - Mint a new CR-CAT -First, select a coin to use for the minting. Flags included in this example (CR-specific flags are in **bold**): +First, select a coin to use for the minting. First, select a coin to use for the minting. Flags included in this example (CR-specific flags are in **bold**): - `--tail`: The tail to use; in this case we'll use a single-issuance TAIL - `--send-to`: The address to send the CR-CATs to upon minting @@ -120,7 +120,7 @@ Response: Name: c5519ac8ef55043b23bef45b1326d445f2c4af579f13dc0cdec10335ccb0a809 ``` -In the above repsonse, `Name` is the ID of the coin to be used for the minting. Next, run the same command again, but remove the `--select-coin` flag and add `--curry 0x` (the `0x` is required and important here): +In the above repsonse, `Name` is the ID of the coin to be used for the minting. In the above repsonse, `Name` is the ID of the coin to be used for the minting. Next, run the same command again, but remove the `--select-coin` flag and add `--curry 0x` (the `0x` is required and important here): ```bash cats --tail ./reference_tails/genesis_by_coin_id.clsp.hex --send-to txch1ek6ln2ejdsec6l734x8tggk9j5sepl8nfqjer5yt2dr905f04prqmcjcc5 --authorized-provider did:chia:1x23lnyd2xjefnfly075ngk79duf0yxna35cp86mgnnp4t33senfs4cah7u --cr-flag "test_proof1" --amount 1000000 -m 1000 --as-bytes --curry 0xc5519ac8ef55043b23bef45b1326d445f2c4af579f13dc0cdec10335ccb0a809 @@ -134,9 +134,9 @@ Asset ID: 262a2c2cbb09414652006c4da139a186b3a110bb57cd5d76b6785e4811f1c77c Eve Coin ID: 692a4f63c56815a33510088a255d695aea472d0f03bb9f0d5cdd5c91a82821f2 ``` -Just as with standard CATs, the CR-CAT has been minted and sent to its destination address. `Asset ID` can now be added in the destination wallet. +Just as with standard CATs, the CR-CAT has been minted and sent to its destination address. `Asset ID` can now be added in the destination wallet. `Asset ID` can now be added in the destination wallet. -In this case, the destination wallet is the holder of a VC with the proof required to hold this CR-CAT. To verify this, run the `vcs get` CLI command: +In this case, the destination wallet is the holder of a VC with the proof required to hold this CR-CAT. To verify this, run the `vcs get` CLI command: To verify this, run the `vcs get` CLI command: ```bash chia wallet vcs get @@ -154,7 +154,7 @@ Inner Address: txch166pzqd55p2emp9sqaflvyc8x2s4qn4eexrxgrlfwf8khuefp5fqswe84mu Proof Hash: f063e22557705b14425b8fca60018796b4364eb6354f45d0b99431a71d3043e5 ``` -This VC contains the proof that was added to the CR-CAT (`test_proof1`). Once the CR-CAT has been added to this Chia wallet, it will be displayed as type `CRCAT`. For example: +This VC contains the proof that was added to the CR-CAT (`test_proof1`). Once the CR-CAT has been added to this Chia wallet, it will be displayed as type `CRCAT`. For example: Once the CR-CAT has been added to this Chia wallet, it will be displayed as type `CRCAT`. For example: ```bash chia wallet show diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/cli.md index c679cc1d61..8a502a05a5 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/cli.md @@ -91,6 +91,22 @@ Command: `chia start {service}` `-r, --restart`: Restart of running processes +| | Full Node | Wallet | Farmer | Harvester | Timelord | Timelord Launcher | Timelord-Only | Introducer | Full Node Simulator | +| ----------------- | --------- | ------ | ------ | --------- | -------- | ----------------- | ------------- | ---------- | ------------------- | +| all | X | X | X | X | X | X | | | | +| node | X | | | | | | | | | +| harvester | | | | X | | | | | | +| farmer | X | X | X | X | | | | | | +| farmer-no-wallet | X | | X | X | | | | | | +| farmer-only | | | X | | | | | | | +| timelord | X | | | | X | X | | | | +| timelord-only | | | | | X | | X | | | +| timelord-launcher | | | | | | X | | | | +| wallet | X | X | | | | | | | | +| wallet-only | | X | | | | | | | | +| introducer | | | | | | | | X | | +| simulator | | | | | | | | | X | + # plotters In 2.1.0 the option to use different plotters including compressed plotter was introduced. Each plotter has slightly different hardware requirements and may need slightly different options specified. The cli reference for all plotters can be found in the [Plotters CLI Page](/plotters-cli). Learn more about the alternative plotters in the [Alternative Plotters page](/plotting-software). @@ -162,7 +178,7 @@ For more detail, you can read about the DiskProver commands in [chiapos](https:/ The plots check challenge is a static challenge. For example if you run a plots check 20 times, with 30 tries against the same file, it will produce the same result every time. So while you may see a plot ratio \<< 1 for a plot check with `x` number of tries, it does not mean that the plot itself is worthless. It just means that given these static challenges, the plot is producing however many proofs. As the number of tries (`-n`) increases, we would expect the ratio to not be \<< 1. Since Mainnet is live, and given that the blockchain has new challenges with every signage point - just because a plot is having a bad time with one specific challenge, does not mean it has the same results versus another challenge. "Number of plots" and "k-size" are much more influential factors at winning blocks than "proofs produced per challenge". -**In theory**, a plot with a ratio >> 1 would be more likely to win challenges on the blockchain. Likewise, a plot with a ratio \<< 1 would be less likely to win. However, in practice, this isn't actually going to be noticeable. Therefore, don't worry if your plot check ratios are less than 1, unless they're _significantly_ less than 1 for _many_ `-n`. +**In theory**, a plot with a ratio >> 1 would be more likely to win challenges on the blockchain. Likewise, a plot with a ratio \<< 1 would be less likely to win. However, in practice, this isn't actually going to be noticeable. Therefore, don't worry if your plot check ratios are less than 1, unless they're _significantly_ less than 1 for _many_ `-n`. Likewise, a plot with a ratio \<< 1 would be less likely to win. However, in practice, this isn't actually going to be noticeable. Therefore, don't worry if your plot check ratios are less than 1, unless they're _significantly_ less than 1 for _many_ `-n`. # db @@ -193,16 +209,16 @@ Command: `chia db backup [add flags and parameters]` **Flags** -`--backup_file [PATH]`: (optional) Specifies the backup file and location. Default will create the backup in the same directory as the database. +`--backup_file [PATH]`: (optional) Specifies the backup file and location. Default will create the backup in the same directory as the database. Default will create the backup in the same directory as the database. `--no_indexes`: (optional) Create backup without indexes. **Database backup notes** -- This will vacuum (compress) and backup your database and may take several hours to complete. Use at your own leisure. +- This will vacuum (compress) and backup your database and may take several hours to complete. Use at your own leisure. Use at your own leisure. - You do not need to stop your Chia node while performing the upgrade. - The new database file will be written to the same folder as the original with "vacuumed\_" prepended to the name. -- To use the backup database: Close the chia client, remove/delete the main database, rename the backup database to remove "vacuumed\_", and restart the chia client. Note the initial start will take extra time as the client verifies the backup db file. +- To use the backup database: Close the chia client, remove/delete the main database, rename the backup database to remove "vacuumed\_", and restart the chia client. Note the initial start will take extra time as the client verifies the backup db file. Note the initial start will take extra time as the client verifies the backup db file. ## [validate](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/db.py) @@ -210,13 +226,13 @@ Command: `chia db validate [add flags and parameters]` **Flags** -`--db [PATH]`: (optional) Specifies which database file to validate. Default will use the default database and path. +`--db [PATH]`: (optional) Specifies which database file to validate. Default will use the default database and path. Default will use the default database and path. -`--validate-blocks`: (optional) Validate consistency of properties of the encoded blocks and block records. Note this will increase the validation time. +`--validate-blocks`: (optional) Validate consistency of properties of the encoded blocks and block records. Note this will increase the validation time. Note this will increase the validation time. **Database validate notes** -- This will validate your database and may take several hours to complete. Use at your own leisure. +- This will validate your database and may take several hours to complete. Use at your own leisure. Use at your own leisure. - You do not need to stop your Chia node while performing the upgrade. - This will start by processing the latest block and traverse to the first block. @@ -342,6 +358,7 @@ Options: Commands: completion Generate shell completion configure Modify configuration + dao Create, manage or show state of DAOs data Manage your data db Manage the blockchain database dev Developer commands and tools diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/daos.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/daos.md index dcc91e48a0..1006d8ada3 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/daos.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/daos.md @@ -143,7 +143,7 @@ Options: | -i | --wallet-id | INTEGER | True | ID of the DAO Treasury Wallet | | -w | --funding-wallet-id | INTEGER | True | The ID of the wallet to send funds from (must be of type `STANDARD_WALLET`) | | -a | --amount | TEXT | True | The amount of funds to send, in XCH | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | | -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | @@ -290,7 +290,7 @@ Options: | -i | --wallet-id | INTEGER | True | ID of the wallet to use | | -p | --proposal-id | TEXT | True | The ID of the proposal you are voting on | | -d | --self-destruct | None | False | If this flag is set, it will self-destruct a broken proposal, thus forcing to force it to close \[default: not set] | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | | -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | @@ -424,7 +424,7 @@ Options: | | --proposal-minimum | INTEGER | False | The minimum amount (in xch) that a proposal must use to be created (this is a spam-prevention measure; it will be donated to the treasury when the proposal is closed) \[default: 0.000000000001] | | | --filter-amount | INTEGER | False | The minimum number of votes a proposal needs before the wallet will recognise it \[default: 1] | | | --cat-amount | INTEGER | True | The number of DAO CATs (in mojos) to create when initializing the DAO | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --fee-for-cat | TEXT | False | Set the fees for the CAT creation transaction, in XCH \[default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | @@ -571,7 +571,7 @@ Options: | -a | --amount | INTEGER | True | The amount of new cats the proposal will mint (in mojos) | | -t | --to-address | TEXT | True | The address new cats will be minted to | | -v | --vote-amount | INTEGER | True | The number of votes to add | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | | -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | @@ -692,7 +692,7 @@ Options: | -v | --vote-amount | INTEGER | True | The number of votes to add | | | --asset-id | TEXT | False | The asset id of the funds the proposal will send. Leave blank for xch | | -j | --from-json | TEXT | False | Path to a json file containing a list of additions, for use in proposals with multiple spends | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | | -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | @@ -830,7 +830,7 @@ Options: | | --pass-percentage | INTEGER | False | The percentage of 'yes' votes in basis points a proposal must receive to be accepted. 100% = 10000 | | | --self-destruct | INTEGER | False | The number of blocks required before a proposal can be automatically removed | | | --oracle-delay | INTEGER | False | The number of blocks required between oracle spends of the treasury | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | | -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | @@ -913,7 +913,7 @@ Options: | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | | -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | | -i | --wallet-id | INTEGER | True | ID of the DAO wallet from which to exit the lockup | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | | -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | @@ -1089,7 +1089,7 @@ Options: | -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | | -i | --wallet-id | INTEGER | True | ID of the DAO wallet to use | | -a | --amount | TEXT | True | The amount of CATs (not mojos) to lock in voting mode | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | | -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | @@ -1220,7 +1220,7 @@ Options: | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | | -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | | -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | | -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | @@ -1399,7 +1399,7 @@ Options: | -p | --proposal-id | TEXT | True | The ID of the proposal you are voting on | | -a | --vote-amount | INTEGER | True | The number of votes you want to cast | | -n | --vote-no | None | False | Use this option to vote against a proposal. If not present then the vote is for the proposal | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH \[default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | | -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/datalayer.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/datalayer.md index 0e486762b7..261279b11b 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/datalayer.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/datalayer.md @@ -169,7 +169,7 @@ Options:
Example -To clear all pending roots, you need to enter the store ID. An example of this which also disables prompting: +To clear all pending roots, you need to enter the store ID. An example of this which also disables prompting: An example of this which also disables prompting: ```bash chia data clear_pending_roots -i 2772c8108e19f9fa98ff7bc7d4bafd821319bc90af6b610d086b85f4c21fa816 --yes @@ -391,8 +391,18 @@ Options: | -r | --root_hash | TEXT | False | The hexadecimal root hash | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | | -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -p | --page | INTEGER | False | Enables pagination of the output and requests a specific page | +| | --max-page-size | INTEGER | False | Set how many bytes to be included in a page, if pagination is enabled [Default: 40 MB] | | -h | --help | None | False | Show a help message and exit | +:::info + +Pagination is disabled by default. If it is enabled (by using the `page` flag), then the JSON response will include `total_pages` and `total_bytes`, in addition to the data. + +If an item is larger than `max-page-size`, an error will be thrown. + +::: +
Example @@ -430,8 +440,18 @@ Options: | -r | --root_hash | TEXT | False | The hexadecimal root hash | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | | -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -p | --page | INTEGER | False | Enables pagination of the output and requests a specific page | +| | --max-page-size | INTEGER | False | Set how many bytes to be included in a page, if pagination is enabled [Default: 40 MB] | | -h | --help | None | False | Show a help message and exit | +:::info + +Pagination is disabled by default. If it is enabled (by using the `page` flag), then the JSON response will include `total_pages` and `total_bytes`, in addition to the data. + +If an item is larger than `max-page-size`, an error will be thrown. + +::: +
Example @@ -480,8 +500,18 @@ Options: | -hash_2 | --hash_2 | TEXT | True | The second hash to compare | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | | -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -p | --page | INTEGER | False | Enables pagination of the output and requests a specific page | +| | --max-page-size | INTEGER | False | Set how many bytes to be included in a page, if pagination is enabled [Default: 40 MB] | | -h | --help | None | False | Show a help message and exit | +:::info + +Pagination is disabled by default. If it is enabled (by using the `page` flag), then the JSON response will include `total_pages` and `total_bytes`, in addition to the data. + +If an item is larger than `max-page-size`, an error will be thrown. + +::: +
Example @@ -598,6 +628,60 @@ Response: --- +### `get_proof` + +Functionality: Obtains a merkle proof of inclusion for a given key + +Usage: `chia data get_proof [OPTIONS]` + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | +| -store | --id | TEXT | True | The hexadecimal store id | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | +| -k | --key | TEXT | True | The hexadecimal key | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | + +The proof is a proof of inclusion that a given key, value pair is in the specified datalayer store by chaining the Merkle hashes up to the published on-chain root hash. + +A user can generate a proof for multiple k,v pairs in the same datastore. + +
+Example + +```bash +chia data get_proof --id 7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e -k 0x0003 +``` + +Response: + +```bash +{ + "proof": { + "coin_id": "0x774e5f9ba7a8afbfa7fd2050347b4a2d400d3cd530637a18b61b094bb5a0f756", + "inner_puzzle_hash": "0x875cc80014bc72f2028c27500d5b44bf6906cd13ad16d7b5f4a5da77a06c8c2f", + "store_proofs": { + "proofs": [ + { + "key_clvm_hash": "0xa143e7ffd81147f136f921fef88760c46c7a05f15b81995f9c5cfed2a737a3f1", + "layers": [], + "node_hash": "0xe488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb", + "value_clvm_hash": "0xed052604ee4ff3996c15ef9b2cb0925233a2e78b6168bb6e67d133e074109b42" + } + ], + "store_id": "0x7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e" + } + }, + "success": true +} +``` + +
+ +--- + ### `get_root` Functionality: Get the Merkle Root and timestamp of a given store ID @@ -1037,6 +1121,8 @@ Options: | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | | -m | --fee | TEXT | False | Set the fees for the transaction, in XCH | | -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| | --submit | None | False | Set to submit the result on chain [Default: don't submit] | +| | --no-submit | None | False | Set to explicitly specify not to submit the result on chain [Default: don't submit] | | -h | --help | None | False | Show a help message and exit | A few notes on the `-d` / `--changelist` option: @@ -1221,6 +1307,73 @@ value = { --- +### `verify_proof` + +Functionality: Verifies a merkle proof of inclusion + +Usage: `chia data verify_proof [OPTIONS]` + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | +| -p | --proof | TEXT | True | Proof to validate in JSON format | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | + +Notes about this command: + +- It only needs to perform a single lookup of the on-chain root. +- It doesn't need to have synced any of the data, or be subscribed to the data store. +- To keep the proofs smaller, only the clvm hash of the key and value are included in the proof, and not the actual key or value. (A clvm hash is just a sha256 hash of the data prepended with 0x01.) +- Datalayer uses CLVM hashes for ease of verification in CLVM, although for this specific use case, there is no on-chain validation happening. +- When using this command, pay attention to the `current_root` value in the returned JSON. + - If `current_root` is `True`, this data chains to the current published root, and so if you synced the data, you can be sure it would be there. + - If `current_root` is `False`, the root has moved from the time the proof was generated. You cannot make any assumptions in this case about whether the data is in fact in the datastore or not since the root has changed, therefore the data might have changed. It is up to the caller to determine how to treat this case; one possible action would be to obtain a new proof. + +The proof to validate requires several fields: + +- `coin_id` +- `inner_puzzle_hash` +- `store_proofs` + - `proofs` + - `key_clvm_hash` + - `value_clvm_hash` + - `node_hash` + - `layers` + +Each of these fields is output with the [get_proof](#get_proof) command. For more examples, see chia-blockchain [PR #16845](https://github.com/Chia-Network/chia-blockchain/pull/16845). + +
+Example + +```bash +chia data verify_proof -p '{"coin_id": "0x774e5f9ba7a8afbfa7fd2050347b4a2d400d3cd530637a18b61b094bb5a0f756", "inner_puzzle_hash": "0x875cc80014bc72f2028c27500d5b44bf6906cd13ad16d7b5f4a5da77a06c8c2f", "store_proofs": {"proofs": [{"key_clvm_hash": "0xa143e7ffd81147f136f921fef88760c46c7a05f15b81995f9c5cfed2a737a3f1","layers": [], "node_hash": "0xe488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb", "value_clvm_hash": "0xed052604ee4ff3996c15ef9b2cb0925233a2e78b6168bb6e67d133e074109b42"}], "store_id": "0x7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e"}}' +``` + +Response: + +```bash +{ + "current_root": true, + "success": true, + "verified_clvm_hashes": { + "inclusions": [ + { + "key_clvm_hash": "0xa143e7ffd81147f136f921fef88760c46c7a05f15b81995f9c5cfed2a737a3f1", + "value_clvm_hash": "0xed052604ee4ff3996c15ef9b2cb0925233a2e78b6168bb6e67d133e074109b42" + } + ], + "store_id": "0x7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e" + } +} +``` + +
+ +--- + ### `wallet_log_in` Functionality: Request that the wallet service be logged in to the specified fingerprint diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/offers.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/offers.md index de8b2cde06..f64afda0cd 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/offers.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/offers.md @@ -45,6 +45,7 @@ Options: | -p | --filepath | TEXT | True | The path to write the generated offer file to | | -m | --fee | TEXT | False | A fee to add to the offer when it gets taken | | | --reuse | None | False | Set this flag to reuse an existing address for the offer [Default: generate a new address] | +| | --override | None | False | Creates offer without checking for unusual values | | -h | --help | None | False | Show a help message and exit | --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/plotters.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/plotters.md index 25afb9cc67..2c82ccf3c2 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/plotters.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/plotters.md @@ -42,8 +42,6 @@ Options: | | --compress | INTEGER | False | Compression level [Default: 0 (not compressed)] | | -h | --help | None | False | Show a help message and exit | ---- - ### `madmax` Functionality: Use the madMAx plotter @@ -112,7 +110,7 @@ Options: A few notes about the `disk-16` option: - As of BladeBit 3.0.1 (Chia 2.1.0), `disk-16` is experimental. -- This option has been disabled in the Chia 2.1.0 release. It is currently only available from the [standalone version](https://github.com/Chia-Network/bladebit/) of BladeBit. +- This option has been disabled in the Chia 2.1.0 release. This option has been disabled in the Chia 2.1.0 release. It is currently only available from the [standalone version](https://github.com/Chia-Network/bladebit/) of BladeBit. - Plots created with this option on Linux with direct I/O disabled appear to work, but more testing is still needed. - Plots created with this option on Windows are more likely to encounter issues. - Be sure to check all plots created with this option, as they could be invalid even if the plotter appeared to succeed. @@ -121,16 +119,14 @@ A few notes about the `disk-16` option: :::info -Computers with at least 256 GB of system memory should not use either the `disk-128` or `disk-16` options. They should also not use `tmp_dir` or `tmp_dir2`. In this case, plotting will be performed entirely in memory. +Computers with at least 256 GB of system memory should not use either the `disk-128` or `disk-16` options. They should also not use `tmp_dir` or `tmp_dir2`. In this case, plotting will be performed entirely in memory. They should also not use `tmp_dir` or `tmp_dir2`. In this case, plotting will be performed entirely in memory. -Computers with at least 128 GB of system memory (but less than 256 GB) should use the `disk-128`, `tmp_dir`, and `tmp_dir2` options. In this case, most of the plotting will be done in memory, and some will be done on disk. +Computers with at least 128 GB of system memory (but less than 256 GB) should use the `disk-128`, `tmp_dir`, and `tmp_dir2` options. In this case, most of the plotting will be done in memory, and some will be done on disk. In this case, most of the plotting will be done in memory, and some will be done on disk. -Linux computers with at least 16 GB of system memory (but less than 128 GB) can use the `disk-16`, `tmp_dir`, and `tmp_dir2` options. However, **do so at your own risk**. (See the above warning for details.) In this case, as much of the plotting as possible will be done in memory, and the rest will be done on disk. +Linux computers with at least 16 GB of system memory (but less than 128 GB) can use the `disk-16`, `tmp_dir`, and `tmp_dir2` options. However, **do so at your own risk**. (See the above warning for details.) In this case, as much of the plotting as possible will be done in memory, and the rest will be done on disk. However, **do so at your own risk**. (See the above warning for details.) In this case, as much of the plotting as possible will be done in memory, and the rest will be done on disk. ::: ---- - ### `ramplot` Functionality: Use the BladeBit RAM plotter @@ -155,8 +151,6 @@ Options: | | --compress | INTEGER | False | Compression level, 0-9 are accepted [Default: 1] | | -h | --help | None | False | Show a help message and exit | ---- - ### `diskplot` Functionality: Use the BladeBit disk plotter @@ -194,8 +188,6 @@ Options: | | --compress | INTEGER | False | Compression level, 0-9 are accepted [Default: 1] | | -h | --help | None | False | Show a help message and exit | ---- - ### `simulate` Functionality: Determine your farm's maximum capacity; this command is **only** avaible with the [standalone version](https://github.com/Chia-Network/bladebit/) of BladeBit. @@ -204,18 +196,94 @@ Usage: bladebit simulate [OPTIONS] \ Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--------- | :------- | :----------------------------------------------------------------------------- | -| -n | --iterations | INTEGER | False | The number of iterations to run [Default: 100] | -| -p | --parallel | INTEGER | False | The number of instances to run in parallel [Default: 1] | -| -l | --lookup | FLOAT | False | Maximum allowed time per proof lookup, in seconds [Default: 8.00] | -| -f | --filter | INTEGER | False | Plot filter bit count [Default: 512] | -| | --partials | INTEGER | False | Partials per-day simulation [Default: 300] | -| | --power | INTEGER | False | Time in seconds to run power simulation. -n is set automatically in this mode. | -| -s | --size | INTEGER | False | Size of farm. Only used when `--power` is set. | -| | --seed | HEX STRING | False | 64 char hex string to use as a random seed for challenges | -| | --no-cuda | None | False | If set, don't use CUDA for decompression. [Default: not set] | -| -d | --device | INTEGER | False | Cuda device index, to be used when more than one device exists [Default: 0] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--------- | :------- | :------------------------------------------------------------------------------------------------------------------- | +| -n | --iterations | INTEGER | False | The number of iterations to run [Default: 100] | +| -p | --parallel | INTEGER | False | The number of instances to run in parallel [Default: 1] | +| -l | --lookup | FLOAT | False | Maximum allowed time per proof lookup, in seconds [Default: 8.00] | +| -f | --filter | INTEGER | False | Plot filter bit count [Default: 512] | +| | --partials | INTEGER | False | Partials per-day simulation [Default: 300] | +| | --power | INTEGER | False | Time in seconds to run power simulation. -n is set automatically in this mode. -n is set automatically in this mode. | +| -s | --size | INTEGER | False | Size of farm. Size of farm. Only used when `--power` is set. | +| | --seed | HEX STRING | False | 64 char hex string to use as a random seed for challenges | +| | --no-cuda | None | False | If set, don't use CUDA for decompression. \[Default: not set\] \[Default: not set\] | +| -d | --device | INTEGER | False | Cuda device index, to be used when more than one device exists [Default: 0] | +| -h | --help | None | False | Show a help message and exit | --- + +## `drplotter` + +Functionality: Use the DrPlotter plotter + +Usage: drplotter \[plot | verify\] \[OPTIONS\] + +### `plot` + +Functionality: Plot with the DrPlotter plotter + +Usage: drplotter plot [OPTIONS] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------ | +| -h | --help | None | False | Show a help message and exit | +| -f | --farmerkey | TEXT | True | Farmer Public Key (48 bytes, hex encoded) | +| -c | --contractkey | TEXT | True | Pool Contract Address (64 chars, hex encoded) | +| -d | --outputDirectory | TEXT | True | Final directory after plot has been created | +| | --compression | TEXT | False | Set compression mode. Choose between eco3x (68 bits per proof), or pro4x (49 bits per proof) [Default: eco3x] | +| -i | --gpu_id | INTEGER | False | GPU ID to use [Default: 0] | +| -n | --n_to_plot | INTEGER | False | Number of plots to create [Default: 0, fills directory] | +| -L | --gpu_memory_limit | INTEGER | False | GPU memory limit in MB [Default: 0 (disabled)] | +| | --min_gpu_ram | None | False | Use min gpu ram | + +### `verify` + +Functionality: Verify plots with the DrPlotter plotter + +Usage: drplotter verify [OPTIONS] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------- | +| -h | --help | None | False | Show a help message and exit | +| -f | --file | TEXT | False | File to read from | +| -d | --directory | TEXT | False | Check all files in directory | + +--- + +## `drsolver` + +Functionality: Use the DrSolver harvester + +Usage: drsolver [OPTIONS] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------- | :------ | :------- | :--------------------------------------------------- | +| -h | --help | None | False | Show a help message and exit | +| -g | --gpu | INTEGER | True | GPU ID to use for solving | +| -v | --verbose | None | False | Verbose output | +| -t | --token | TEXT | True | Client token to use for registration | +| | --generate-token | None | False | Generate a client token | +| | --drserver-ip | TEXT | True | Your own DrServer, at IP:PORT, e.g. 192.168.0.1:8080 | +| | --ssl | BOOLEAN | False | Use SSL for your solver server [Default: false] | + +--- + +## `drserver` + +Functionality: Use the DrServer harvester + +Usage: drserver [OPTIONS] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------ | :------- | :--------------------------- | +| -h | --help | None | False | Show a help message and exit | +| -p | --port | INTEGER | True | Server port | +| -t | --token | TEXT | True | Server token | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/vcs.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/vcs.md index ba131ee7e3..7b070d0932 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/vcs.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/vcs.md @@ -146,19 +146,19 @@ Usage: chia wallet vcs mint [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use as the issuing wallet | -| -d | --did | TEXT | True | The DID of the VC's proof provider. Must be owned by the issuing wallet | -| -t | --target-address | TEXT | False | The address to send the VC to once it's minted [Default: send to minting wallet] | -| -m | --fee | TEXT | False | Blockchain fee for mint transaction, in XCH | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use as the issuing wallet | +| -d | --did | TEXT | True | The DID of the VC's proof provider. Must be owned by the issuing wallet Must be owned by the issuing wallet | +| -t | --target-address | TEXT | False | The address to send the VC to once it's minted [Default: send to minting wallet] | +| -m | --fee | TEXT | False | Blockchain fee for mint transaction, in XCH | +| -h | --help | None | False | Show a help message and exit |
Example -A DID is required in order to mint a new VC. If the proof provider does not already have a DID, use the `did create` command to create one. For example: +A DID is required in order to mint a new VC. A DID is required in order to mint a new VC. If the proof provider does not already have a DID, use the `did create` command to create one. For example: For example: ```bash chia wallet did create -f 2108245669 -n Provider_DID -m 0.0001 @@ -171,7 +171,7 @@ Successfully created a DID wallet with name Provider_DID and id 2 on key 2108245 Successfully created a DID did:chia:1n2s77g7rer2v62xzrvd0at6tgx8m4g8t6encghs375r64lc6e5mssdkap3 in the newly created DID wallet ``` -Next, mint a new VC. Note that the DID specified with `-d` must be owned by the fingerprint specified with `-f` (or the one selected if `-f` is not used). For example: +Next, mint a new VC. Next, mint a new VC. Note that the DID specified with `-d` must be owned by the fingerprint specified with `-f` (or the one selected if `-f` is not used). For example: For example: ```bash chia wallet vcs mint -f 2108245669 -d did:chia:1n2s77g7rer2v62xzrvd0at6tgx8m4g8t6encghs375r64lc6e5mssdkap3 -m 0.0001 @@ -208,7 +208,7 @@ Inner Address: txch1at35qwx6djmadnh9v77a72z8vcaxsle36ke3dj26gcpt2fnh654qsqecnj It is recommended that you save the `Launcher ID` because it will be needed if the VC needs to be revoked later. -No proofs have been added yet. This is accomplished with the [update_proofs](#update_proofs) command. +No proofs have been added yet. No proofs have been added yet. This is accomplished with the [update_proofs](#update_proofs) command.
@@ -222,21 +222,21 @@ Usage: chia wallet vcs revoke [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :--------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -p | --parent-coin-id | TEXT | True\* | The ID of the parent coin of the VC (\*optional if VC ID is used) | -| -l | --vc-id TEXT | TEXT | True\* | The launcher ID of the VC to revoke (must be tracked by wallet) (\*optional if Parent ID is used) | -| -m | --fee | TEXT | False | Blockchain fee for revocation transaction, in XCH | -| | --reuse-puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from (ignored if `--generate-new-puzhash` is also specified) [Default: generate new puzzle hash] | -| | --generate-new-puzhash | None | False | If this flag is set, then send the VC to a new puzzle hash. This is the default behavior, and setting this flag will override the `--reuse-puzhash` flag if it is also set | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -p | --parent-coin-id | TEXT | True\* | The ID of the parent coin of the VC (\*optional if VC ID is used) | +| -l | --vc-id TEXT | TEXT | True\* | The launcher ID of the VC to revoke (must be tracked by wallet) (\*optional if Parent ID is used) | +| -m | --fee | TEXT | False | Blockchain fee for revocation transaction, in XCH | +| | --reuse-puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from (ignored if `--generate-new-puzhash` is also specified) [Default: generate new puzzle hash] | +| | --generate-new-puzhash | None | False | If this flag is set, then send the VC to a new puzzle hash. This is the default behavior, and setting this flag will override the `--reuse-puzhash` flag if it is also set This is the default behavior, and setting this flag will override the `--reuse-puzhash` flag if it is also set | +| -h | --help | None | False | Show a help message and exit |
Example -Revoke the proofs from a VC. A few notes: +Revoke the proofs from a VC. A few notes: A few notes: - The only wallet authorized to call this command is the wallet that contains the DID that created the VC @@ -248,19 +248,20 @@ Response: ```bash VC successfully revoked! +Proofs successfully updated! Relevant TX records: -Transaction 286cc31575aa167c4b34cbc0a768a162caefb6afea77560db0693934ac3fbf1e +Transaction 76f5ea8475d695e798518cd405070dc22542e31fc85220ff7d2ca7b44852a45b Status: Pending -Amount sent: 1E-12 XCH -To address: txch1ehkl33dypc7mg820c7j94zfg8pz5j5lqtx7253nmxft52ryvzw8stx7czc -Created at: 2023-06-23 13:33:50 +Amount sent: 0 XCH +To address: txch10xjm79zct87gc8ux5vzrhnnt03zjn4ntn5y95w37rsfmp4rxjycquqctuc +Created at: 2023-06-15 10:15:27 -Transaction ae6378e84742ab6abb07df666291093938ec9e06ae8e2b4066d7386d94289ba3 +Transaction f9eebb0520d024aaf4ae176d554c0f806b8d724d21d5da03b5f541fafd69c99f Status: Pending -Amount sent: 0 XCH -To address: txch1mahlm65l8q9frcqcfveekx3a29cd74w6gfajqy05ukz2afrzg03syqkz3p -Created at: 2023-06-23 13:33:50 +Amount sent: 1E-12 XCH +To address: txch1dlyh9rwd9y6clt3pjjs3gh25ck9vlfx7qwqvvru27dmhgtn80z9s2rruam +Created at: 2023-06-15 10:15:28 ``` After the transactions have completed, the holder of the VC can now show that the VC does not contain any proofs: @@ -287,22 +288,22 @@ Usage: chia wallet vcs update_proofs [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :--------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -l | --vc-id | TEXT | True | The launcher ID of the VC whose proofs should be updated | -| -t | --new-puzhash | TEXT | False | The puzzle hash to which to send the VC after the proofs have been updated | -| -p | --new-proof-hash | TEXT | True | The new proof hash to update the VC to | -| -m | --fee | TEXT | False | Blockchain fee for update transaction, in XCH | -| | --reuse-puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from (ignored if `--generate-new-puzhash` is also specified) [Default: generate new puzzle hash] | -| | --generate-new-puzhash | None | False | If this flag is set, then send the VC to a new puzzle hash. This is the default behavior, and setting this flag will override the `--reuse-puzhash` flag if it is also set | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -l | --vc-id | TEXT | True | The launcher ID of the VC whose proofs should be updated | +| -t | --new-puzhash | TEXT | False | The puzzle hash to which to send the VC after the proofs have been updated | +| -p | --new-proof-hash | TEXT | True | The new proof hash to update the VC to | +| -m | --fee | TEXT | False | Blockchain fee for update transaction, in XCH | +| | --reuse-puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from (ignored if `--generate-new-puzhash` is also specified) [Default: generate new puzzle hash] | +| | --generate-new-puzhash | None | False | If this flag is set, then send the VC to a new puzzle hash. This is the default behavior, and setting this flag will override the `--reuse-puzhash` flag if it is also set This is the default behavior, and setting this flag will override the `--reuse-puzhash` flag if it is also set | +| -h | --help | None | False | Show a help message and exit |
Example -Update the proofs. A few notes: +Update the proofs. A few notes: A few notes: - The only wallet authorized to call this command is the wallet that contains the DID that created the VC - The `-t` parameter must point to a puzzle hash, not an address diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/wallet.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/wallet.md index 68426b2c3a..e0649ea275 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/wallet.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cli-reference/wallet.md @@ -302,7 +302,7 @@ Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb ### `combine` -Functionality: Combine coins (typically used for combining dust). The maximum number of coins that can be combined within a single transaction is 500. +Functionality: Combine coins (typically used for combining dust). Functionality: Combine coins (typically used for combining dust). The maximum number of coins that can be combined within a single transaction is 500. Usage: chia wallet coins combine [OPTIONS] @@ -912,21 +912,21 @@ Usage: chia wallet delete_unconfirmed_transactions [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -ids | --tx_ids | TEXT | True | IDs of the Clawback transactions you want to revert or claim. Separate multiple IDs by comma (,) | -| -m | --fee | TEXT | False | A fee to add to the offer when it gets taken, in XCH [default: 0] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -ids | --tx_ids | TEXT | True | IDs of the Clawback transactions you want to revert or claim. Separate multiple IDs by comma (,) Separate multiple IDs by comma (,) | +| -m | --fee | TEXT | False | A fee to add to the offer when it gets taken, in XCH [default: 0] | +| -h | --help | None | False | Show a help message and exit | Note that wallet will automatically detect whether the transactions should be reverted (clawed back) or claimed.
Example 1: clawback -First, create the clawback. This is a normal `send` command, with an extra `--clawback` timer: +First, create the clawback. First, create the clawback. This is a normal `send` command, with an extra `--clawback` timer: ```bash chia wallet send -f 4045726944 -a 1 -e "Sending 1 TXCH with 1-hour clawback" -m 0.0001 -t txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze --clawback_time 3600 @@ -936,6 +936,7 @@ Response: ``` Submitting transaction... +Submitting transaction... Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab', 'inclusion_status': 'SUCCESS', 'error_msg': None}] Run 'chia wallet get_transaction -f 4045726944 -tx 0x5a41dbe755a7a44b827b61cfa384e79bef5f79370f63fa7ffe1ea29212a26bf6' to get status ``` @@ -998,6 +999,7 @@ Response: ```bash Submitting transaction... +Submitting transaction... Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab', 'inclusion_status': 'SUCCESS', 'error_msg': None}] Run 'chia wallet get_transaction -f 4045726944 -tx 0x3ca82042aba188d47a80b663523847fa6050a21e04647c7b31ad3aa9d8d5450f' to get status ``` @@ -1353,6 +1355,8 @@ Status: Confirmed Amount received: 10 CAT aaee6b63bcbc4aef... To address: txch1stn20rhgmh5wvmyyfj2etdpdp73fla0ga4ymtsejz600dszf392s58kx2s Created at: 2022-12-14 00:40:39 +To address: txch1stn20rhgmh5wvmyyfj2etdpdp73fla0ga4ymtsejz600dszf392s58kx2s +Created at: 2022-12-14 00:40:39 ```
@@ -1485,22 +1489,22 @@ Usage: chia wallet send [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | -| -a | --amount | TEXT | True | How much chia to send, in XCH | -| -e | --memo | TEXT | False | Additional memo for the transaction | -| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH [default: 0] | -| -t | --address | TEXT | True | Address to send the XCH | -| -o | --override | None | False | Submits transaction without checking for unusual values [default: disabled] | -| -ma | --min-coin-amount | TEXT | False | Ignore coins worth less then this much (XCH or CAT units) | -| -l | --max-coin-amount | TEXT | False | Ignore coins worth more then this much (XCH or CAT units) | -| | --exclude-coin | TEXT | False | Exclude this coin from being spent | -| | --reuse | None | False | Set this flag to reuse an existing address for the change [default: not set] | -| | --clawback_time | INTEGER | False | The seconds that the recipient needs to wait to claim the fund. A positive number will enable this feature | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| -a | --amount | TEXT | True | How much chia to send, in XCH | +| -e | --memo | TEXT | False | Additional memo for the transaction | +| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH [default: 0] | +| -t | --address | TEXT | True | Address to send the XCH | +| -o | --override | None | False | Submits transaction without checking for unusual values [default: disabled] | +| -ma | --min-coin-amount | TEXT | False | Ignore coins worth less then this much (XCH or CAT units) | +| -l | --max-coin-amount | TEXT | False | Ignore coins worth more then this much (XCH or CAT units) | +| | --exclude-coin | TEXT | False | Exclude this coin from being spent | +| | --reuse | None | False | Set this flag to reuse an existing address for the change [default: not set] | +| | --clawback_time | INTEGER | False | The seconds that the recipient needs to wait to claim the fund. A positive number will enable this feature A positive number will enable this feature | +| -h | --help | None | False | Show a help message and exit |
Example 1: send with memo @@ -1534,6 +1538,7 @@ Response: ``` Submitting transaction... +Submitting transaction... Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab', 'inclusion_status': 'SUCCESS', 'error_msg': None}] Run 'chia wallet get_transaction -f 4045726944 -tx 0x3012893bf84b66c849f54b1c4bd893000188a7f728e439d3d6634048e8474482' to get status ``` @@ -1554,7 +1559,7 @@ To address: txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze Created at: 2023-06-14 10:07:51 ``` -Note that the status is `Confirmed` even though it is a pending clawback transaction. This is because the original transaction _has_ been confirmed and a new pending clawback transaction has been created. +Note that the status is `Confirmed` even though it is a pending clawback transaction. Note that the status is `Confirmed` even though it is a pending clawback transaction. This is because the original transaction _has_ been confirmed and a new pending clawback transaction has been created. To view the pending clawback transaction, call `get_transactions` and include the `--clawback` flag (`-l 1` is used here to show only the latest transaction): diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/coin-set-model/conditions.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/coin-set-model/conditions.md index 5b974dcb8f..2103dfcf71 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/coin-set-model/conditions.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/coin-set-model/conditions.md @@ -13,24 +13,21 @@ There are two kinds of conditions. Some require something to be true (such as ti :::warning -Be vigilant when using `ASSERT_MY_COIN_ID` as a shortcut for validating the parent coin ID, puzzle hash, and amount. If they are passed into the solution separately, then validated all at once by hashing them together, it is possible to shift the bytes to the left or right and manipulate the values. +Be vigilant when using `ASSERT_MY_COIN_ID` as a shortcut for validating the parent coin ID, puzzle hash, and amount. If they are passed into the solution separately, then validated all at once by hashing them together, it is possible to shift the bytes to the left or right and manipulate the values. If they are passed into the solution separately, then validated all at once by hashing them together, it is possible to shift the bytes to the left or right and manipulate the values. -You are recommended to use the `coinid` operator when computing coin IDs. This operator was introduced with [CHIP-11](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md). It verifies that hashes are indeed 32 bytes in length, at no extra CLVM cost versus verifying the parent ID, puzzle hash, and amount individually. The `coinid` operator, as well as the other CHIP-11 operators, are described on the Chialisp [operators page](https://chialisp.com/operators#chip-0011-operators). +You are recommended to use the `coinid` operator when computing coin IDs. This operator was introduced with [CHIP-11](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md). It verifies that hashes are indeed 32 bytes in length, at no extra CLVM cost versus verifying the parent ID, puzzle hash, and amount individually. The `coinid` operator, as well as the other CHIP-11 operators, are described on the Chialisp [operators page](https://chialisp.com/operators#chip-0011-operators). This operator was introduced with [CHIP-11](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md). It verifies that hashes are indeed 32 bytes in length, at no extra CLVM cost versus verifying the parent ID, puzzle hash, and amount individually. The `coinid` operator, as well as the other CHIP-11 operators, are described on the Chialisp [operators page](https://chialisp.com/operators#chip-0011-operators). ::: :::warning -`ASSERT_COIN_ANNOUNCEMENT` and `ASSERT_PUZZLE_ANNOUNCEMENT` should typically only be used in a puzzle's _solution_, and not in the puzzle itself. This is especially important when using `ASSERT_COIN_ANNOUNCEMENT`, because it refers to a specific coin. +`ASSERT_COIN_ANNOUNCEMENT` and `ASSERT_PUZZLE_ANNOUNCEMENT` should typically only be used in a puzzle's _solution_, and not in the puzzle itself. This is especially important when using `ASSERT_COIN_ANNOUNCEMENT`, because it refers to a specific coin. This is especially important when using `ASSERT_COIN_ANNOUNCEMENT`, because it refers to a specific coin. -To illustrate the danger, let's say `coin A` uses this condition in its puzzle, and it asserts a coin announcement from `coin B`. -In this case, `coin A` requires `coin B` to be spent in the same block as it is spent. -If `coin B` is spent before `coin A`, then `coin A` can _never_ be spent. +To illustrate the danger, let's say `coin A` uses this condition in its puzzle, and it asserts a coin announcement from `coin B`. In this case, `coin A` requires `coin B` to be spent in the same block as it is spent. If `coin B` is spent before `coin A`, then `coin A` can _never_ be spent. However, if this condition is instead used in the _solution_ for `coin A`, and `coin B` has already been spent, then `coin A` can still be spent later, albeit with a different solution. -It is somewhat less dangerous to use `ASSERT_PUZZLE_ANNOUNCEMENT` in a coin's puzzle because it only relies on a coin with a specific puzzle, and many such coins might exist. -However, it is still best practice to only use this condition in a coin's solution. +It is somewhat less dangerous to use `ASSERT_PUZZLE_ANNOUNCEMENT` in a coin's puzzle because it only relies on a coin with a specific puzzle, and many such coins might exist. However, it is still best practice to only use this condition in a coin's solution. ::: @@ -49,10 +46,12 @@ This condition has no parameters. :::info This condition is part of [CHIP-0011](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md), and will be available at block height 5,496,000. ::: +::: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) of 1,200,000. ::: +::: Format: `(43 public_key message)` @@ -75,10 +74,12 @@ The following parameters are expected: :::info This condition is part of [CHIP-0011](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md), and will be available at block height 5,496,000. ::: +::: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) of 1,200,000. ::: +::: Format: `(44 public_key message)` @@ -101,10 +102,12 @@ The following parameters are expected: :::info This condition is part of [CHIP-0011](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md), and will be available at block height 5,496,000. ::: +::: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) of 1,200,000. ::: +::: Format: `(45 public_key message)` @@ -127,10 +130,12 @@ The following parameters are expected: :::info This condition is part of [CHIP-0011](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md), and will be available at block height 5,496,000. ::: +::: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) of 1,200,000. ::: +::: Format: `(46 public_key message)` @@ -154,10 +159,12 @@ The following parameters are expected: :::info This condition is part of [CHIP-0011](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md), and will be available at block height 5,496,000. ::: +::: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) of 1,200,000. ::: +::: Format: `(47 public_key message)` @@ -181,10 +188,12 @@ The following parameters are expected: :::info This condition is part of [CHIP-0011](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md), and will be available at block height 5,496,000. ::: +::: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) of 1,200,000. ::: +::: Format: `(48 public_key message)` @@ -208,10 +217,11 @@ The following parameters are expected: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) of 1,200,000. ::: +::: Format: `(49 public_key message)` -Verifies a signature for a given message. For [security reasons](https://github.com/Chia-Network/post-mortem/blob/main/2023-05/2023-05-08-AGG_SIG_UNSAFE-can-mimic-AGG_SIG_ME-condition.md), domain strings are not permitted at the end of `AGG_SIG_UNSAFE` messages. +Verifies a signature for a given message. Verifies a signature for a given message. For [security reasons](https://github.com/Chia-Network/post-mortem/blob/main/2023-05/2023-05-08-AGG_SIG_UNSAFE-can-mimic-AGG_SIG_ME-condition.md), domain strings are not permitted at the end of `AGG_SIG_UNSAFE` messages. The following parameters are expected: @@ -225,12 +235,13 @@ The following parameters are expected: ### 50 `AGG_SIG_ME` {#agg-sig-me} :::tip -In most cases, `AGG_SIG_ME` is the recommended condition for requiring signatures. Signatures created for a specific coin spend will only be valid for that exact coin, which prevents an attacker from reusing the signature for other spends. +In most cases, `AGG_SIG_ME` is the recommended condition for requiring signatures. Signatures created for a specific coin spend will only be valid for that exact coin, which prevents an attacker from reusing the signature for other spends. ::: Signatures created for a specific coin spend will only be valid for that exact coin, which prevents an attacker from reusing the signature for other spends. ::: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) of 1,200,000. ::: +::: Format: `(50 public_key message)` @@ -253,10 +264,11 @@ The following parameters are expected: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) of 1,800,000. ::: +::: Format: `(51 puzzle_hash amount (...memos)?)` -Creates a new coin output with a given puzzle hash and amount. This coin is its parent. +Creates a new coin output with a given puzzle hash and amount. This coin is its parent. This coin is its parent. For more information on the `memos` parameter, see the section on [Memos and Hinting](#memos). @@ -288,7 +300,7 @@ The following parameters are expected: Format: `(60 message)` -Creates an announcement of a given message, tied to this coin's id. For more details, see the section on [Announcements](#announcements). +Creates an announcement of a given message, tied to this coin's id. For more details, see the section on [Announcements](#announcements). For more details, see the section on [Announcements](#announcements). The following parameters are expected: @@ -302,7 +314,7 @@ The following parameters are expected: Format: `(61 announcement_id)` -Asserts an announcement with a given id, which is calculated as `sha256(coin_id + message)`. For more details, see the section on [Announcements](#announcements). +Asserts an announcement with a given id, which is calculated as `sha256(coin_id + message)`. For more details, see the section on [Announcements](#announcements). For more details, see the section on [Announcements](#announcements). The following parameters are expected: @@ -316,7 +328,7 @@ The following parameters are expected: Format: `(62 message)` -Creates an announcement of a given message, tied to this coin's puzzle hash. For more details, see the section on [Announcements](#announcements). +Creates an announcement of a given message, tied to this coin's puzzle hash. For more details, see the section on [Announcements](#announcements). For more details, see the section on [Announcements](#announcements). The following parameters are expected: @@ -330,7 +342,7 @@ The following parameters are expected: Format: `(63 announcement_id)` -Asserts an announcement with a given id, which is calculated as `sha256(puzzle_hash + message)`. For more details, see the section on [Announcements](#announcements). +Asserts an announcement with a given id, which is calculated as `sha256(puzzle_hash + message)`. For more details, see the section on [Announcements](#announcements). For more details, see the section on [Announcements](#announcements). The following parameters are expected: @@ -579,16 +591,18 @@ The following parameters are expected: :::info This condition is part of [CHIP-0011](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md), and will be available at block height 5,496,000. ::: +::: :::note This condition adds an additional [CLVM cost](/coin-set-costs/) equal to whatever the value of the first argument is. ::: +::: Format: `(90 cost ...args)` -Allows future conditions with non-zero CLVM costs to be added as soft forks. This functionality was previously only possible as a hard fork. +Allows future conditions with non-zero CLVM costs to be added as soft forks. This functionality was previously only possible as a hard fork. This functionality was previously only possible as a hard fork. -The cost of the condition is specified in ten-thousands, and further arguments are not specified (the soft-forked condition defines these). The reason to scale the cost by 10,000 is to make the argument smaller. For example, a cost of 100 in this condition would equate to an actual cost of 1 million (1,000,000). The cost argument is two bytes, with a maximum size of 65,535 (an actual cost of 655,350,000). +The cost of the condition is specified in ten-thousands, and further arguments are not specified (the soft-forked condition defines these). The cost of the condition is specified in ten-thousands, and further arguments are not specified (the soft-forked condition defines these). The reason to scale the cost by 10,000 is to make the argument smaller. For example, a cost of 100 in this condition would equate to an actual cost of 1 million (1,000,000). The cost argument is two bytes, with a maximum size of 65,535 (an actual cost of 655,350,000). For example, a cost of 100 in this condition would equate to an actual cost of 1 million (1,000,000). The cost argument is two bytes, with a maximum size of 65,535 (an actual cost of 655,350,000). The following parameters are expected: @@ -599,7 +613,7 @@ The following parameters are expected: ## Memos and Hinting {#memos} -When a coin uses one or more outer puzzles that change their puzzle hash, it's challenging for wallets to know which coins they have the ability to spend. The memos field allows you to hint the inner puzzle hash of created coins, which consequently lets the wallet know that the coin belongs to it. Coins can be looked up by the inner puzzle hash rather than the outer puzzle hash. +When a coin uses one or more outer puzzles that change their puzzle hash, it's challenging for wallets to know which coins they have the ability to spend. When a coin uses one or more outer puzzles that change their puzzle hash, it's challenging for wallets to know which coins they have the ability to spend. The memos field allows you to hint the inner puzzle hash of created coins, which consequently lets the wallet know that the coin belongs to it. Coins can be looked up by the inner puzzle hash rather than the outer puzzle hash. Coins can be looked up by the inner puzzle hash rather than the outer puzzle hash. The `CREATE_COIN` condition is defined as a list containing the opcode `51` and the following arguments: @@ -610,26 +624,26 @@ The `CREATE_COIN` condition is defined as a list containing the opcode `51` and The `memos` parameter is an optional list, which must be null terminated. -If `memos` is present, and the first memo is exactly 32 bytes long, it's used as the hint and the rest of the list are memos. Otherwise, values in the entire list are memos. +If `memos` is present, and the first memo is exactly 32 bytes long, it's used as the hint and the rest of the list are memos. Otherwise, values in the entire list are memos. Otherwise, values in the entire list are memos. As an example, the following inner solution for the [standard transaction](https://chialisp.com/standard-transactions) would create an unhinted coin: ```chialisp -(() (q . ((51 target_puzzle_hash amount))) ()) +(() (q . (() (q . ((51 target_puzzle_hash amount))) ()) ``` The following solution would instead create a coin with the hint matching the inner puzzle hash: ```chialisp -(() (q . ((51 target_puzzle_hash amount (target_puzzle_hash)))) ()) +(() (q . (() (q . ((51 target_puzzle_hash amount (target_puzzle_hash)))) ()) ``` This `CREATE_COIN` condition creates the same coin as before, but now it specifies the hint with which the receiving wallet can look up to find this coin. -Hints are only necessary for outer puzzles, of which the inner puzzle hash matches the hint. For example, coins using the standard transaction itself with no outer puzzle do not need a hint. +Hints are only necessary for outer puzzles, of which the inner puzzle hash matches the hint. Hints are only necessary for outer puzzles, of which the inner puzzle hash matches the hint. For example, coins using the standard transaction itself with no outer puzzle do not need a hint. ## Announcements Announcements are ephemeral, meaning that they don't last forever. They can only be asserted within the block they are created. Their purpose is to ensure multiple coins are spent together, either for fees, verification, or as a security measure. -For coin announcements, the id is the `coin_id` and `message` sha256 hashed together. Likewise, for puzzle announcements, it's the `puzzle_hash` and `message` sha256 hashed together. +For coin announcements, the id is the `coin_id` and `message` sha256 hashed together. For coin announcements, the id is the `coin_id` and `message` sha256 hashed together. Likewise, for puzzle announcements, it's the `puzzle_hash` and `message` sha256 hashed together. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/coin-set-model/costs.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/coin-set-model/costs.md index 066d2a9d96..c920ab516a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/coin-set-model/costs.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/coin-set-model/costs.md @@ -3,7 +3,7 @@ title: Costs slug: /coin-set-costs --- -Cost is a unit of measurement that is used to represent the available space in a block. It is measured by the amount of computing power required to execute the programs within it, as well as the physical drive space required to store data on each node's machine. +Cost is a unit of measurement that represents resources expended to record a transaction in a block. Cost is a unit of measurement that is used to represent the available space in a block. It is measured by the amount of computing power required to execute the programs within it, as well as the physical drive space required to store data on each node's machine. :::info The maximum cost per block is 11,000,000,000 (11 billion), which is typically equivalent to around 400 KB of space. However, not every block is completely full. @@ -13,9 +13,9 @@ It is important to keep the cost usage of programs on the Chia blockchain as low ## Cost Calculation -Every CLVM program uses a certain amount of cost during execution, based on the operators and the values they are called on. You can refer to the [Cost page](https://chialisp.com/costs) on the Chialisp website to learn more about the cost of various CLVM operators. +Cost has several components. First, every CLVM program uses a certain amount of cost during execution, based on the operators and the values they are called on. You can refer to the [Cost page](https://chialisp.com/costs) on the Chialisp website to learn more about the cost of various CLVM operators. -Additionally, certain conditions in a coin spend have a cost associated with them as well. A few common examples are [`CREATE_COIN`](https://chialisp.com/conditions#create-coin) and [`AGG_SIG_ME`](/conditions#agg-sig-me), which are expensive operations. +Additionally, certain conditions in a coin spend have a cost associated with them as well. Additionally, certain conditions in a coin spend have a cost associated with them as well. A few common examples are [`CREATE_COIN`](https://chialisp.com/conditions#create-coin) and [`AGG_SIG_ME`](/conditions#agg-sig-me), which are expensive operations. Finally, each byte of data that gets added to the blockchain has a cost of 12,000. Spend bundles are created using a serialized format of CLVM programs, calculated by running [opc](https://chialisp.com/commands#serialize) on the original CLVM program. Each two-digit pair of this format is equivalent to one byte, which costs 12,000 to store on the blockchain. @@ -25,7 +25,7 @@ Aside from cost, the maximum number of atoms and pairs (counted separately) in a The minimum spec machine to run a full node is the Raspberry Pi 4. How do we know if this machine can stay synced? The worst case scenario occurs when multiple full transaction blocks are created with the minimum amount of time between them. This will temporarily put maximum load on the system. If the Pi can stay synced in this scenario, then it easily should be able to stay synced under normal load. -The first question we must answer is how much time elapses between transaction blocks. Chia's consensus mandates that at least three signage points must be reached before infusion_iterations may occur, so the minimum time between blocks is the following: +The first question we must answer is how much time elapses between transaction blocks. The first question we must answer is how much time elapses between transaction blocks. Chia's consensus mandates that at least three signage points must be reached before infusion_iterations may occur, so the minimum time between blocks is the following: ``` 3 signage points * signage point time @@ -137,3 +137,31 @@ Theoretical maximum cost per block: `3 620 074 957 + 3 620 074 957 + 3 620 074 9 The theoretical maximum size of a single block is `maximum cost per block / cost per byte`, or `11 000 000 000 / 12 000 = 916 667 bytes`. However, this number ignores the costs of all operators. If you want a CLVM program to do anything useful, the maximum size would be closer to 400 KB. Even this number is not realistic because it assumes that a single program will take up an entire block. The maximum number of vanilla transactions (with two outputs) per block is 1000. Therefore, if there is fee pressure on Chia's blockchain, a 400 KB program would need to include a larger fee than the top 1000 vanilla transactions in the mempool -- combined -- in order for a farmer to include it. + +### Estimated Transaction Costs + +The below chart contains costs for various transactions on the blockchain, each of these assumes the inputs and outputs have been optimized and represent a best case scenario. + +:::note +The [minimum effective](/mempool/#fee-required-for-inclusion) fee represents 5 x the clvm cost and is the minimum fee recognized by the default consensus rules (any fee less would be the same as 1 mojo). This means one needs to use at least the fees listed below during moderate fee pressure but greater fees might be needed for time sensitive transactions to process in a timely manner. + +Please note that the costs and fees listed are for vanilla versions of these transactions, they can vary based on the number of input and output coins needed so consider these the bare minimum. Transactions with a '\*' are listed with a fee of 3 x the minimum effective fee. This is to ensure the fees are more realistic for how coins are distributed in users wallets but note that vanilla versions of these would be 1/3 that which is listed. +::: + +| Transaction Type | clvm Cost | Minimum Effective Fee | +| --------------------------------- | ------------- | --------------------------------- | +| **Full Block (with 50% cap)** | 5,500,000,000 | 27,500,000,000 mojo (0.0275 xch) | +| **Standard Transaction** | 6,000,000 | 90,000,000 mojo (0.00009 xch) \* | +| **PlotNFT Creation** | 18,000,000 | 90,000,000 mojo (0.00009 xch) | +| **Minting NFT with DID** | 123,000,000 | 615,000,000 mojo (0.000615 xch) | +| **Minting NFT without DID** | 53,000,000 | 265,000,000 mojo (0.000265 xch) | +| **Adding URI to NFT with DID** | 71,000,000 | 355,000,000 mojo (0.000355 xch) | +| **Adding URI to NFT without DID** | 41,000,000 | 205,000,000 mojo (0.000205 xch) | +| **Transfer NFT with DID** | 67,000,000 | 335,000,000 mojo (0.000335 xch) | +| **Assign DID to NFT** | 107,000,000 | 535,000,000 mojo (0.000535 xch) | +| **Send Clawback Transaction** | 10,000,000 | 150,000,000 mojo (0.00015 xch) \* | +| **Claim Clawback Transaction** | 1,400,000 | 7,000,000 mojo (.000007 xch) | +| **Clawback Clawback Transaction** | 15,600,000 | 75,800,000 mojo (.0000758 xch) | +| **Combine 500 Farming Rewards** | 3,100,000,000 | 15,500,000,000 mojo (.0155 xch) | +| **Split 1 Coin into 2** | 11,000,000 | 55,000,000 mojo (.000055 xch) | +| **Cat Transaction** | 37,000,000 | 555,000,000 mojo (.000555 xch) \* | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/challenges.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/challenges.md index a730515681..350d14a959 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/challenges.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/challenges.md @@ -45,9 +45,9 @@ In the networking protocol, the three VDF proofs are usually passed around toget ## Genesis Challenge -The genesis challenge is the first challenge on a network that uses the Proof of Space and Time consensus. The timelords use this challenge to calculate and broadcast the very first signage point. Chia's mainnet, testnets and simulated networks each have their own unique _genesis challenge_. +The genesis challenge is the first challenge on a network that uses the Proof of Space and Time consensus. The timelords use this challenge to calculate and broadcast the very first signage point. Chia's mainnet, testnets and simulated networks each have their own unique _genesis challenge_. The timelords use this challenge to calculate and broadcast the very first signage point. Chia's mainnet, testnets and simulated networks each have their own unique _genesis challenge_. -The genesis challenge is created arbitrarily, by hashing a preimage. In the case of Chia's mainnet, the preimage included the hash of Bitcoin block [675317](https://www.blockchain.com/explorer/blocks/btc/675317), which was mined shortly prior to the launch of Chia's network. It also included the following message from Bram: +The genesis challenge is created arbitrarily, by hashing a preimage. The genesis challenge is created arbitrarily, by hashing a preimage. In the case of Chia's mainnet, the preimage included the hash of Bitcoin block [675317](https://www.blockchain.com/explorer/blocks/btc/675317), which was mined shortly prior to the launch of Chia's network. It also included the following message from Bram: It also included the following message from Bram: `"Operational error causes Fed payment system to crash" We stand on the shoulders of giants, now let's get farming!` @@ -63,6 +63,6 @@ The SHA256 hash of this preimage is: ccd5bb71183532bff220ba46c268991a3ff07eb358e8255a65c30a2dce0e5fbb ``` -This hash is the genesis challenge for Chia's mainnet. The complete JSON data for the genesis challenge is located [here](https://download.chia.net/notify/mainnet_alert.txt). The first block on Chia's mainnet ([block 0](https://www.spacescan.io/block/0)) was created at signage point `2`; it points to the genesis challenge as its previous block. The prefarm was then distributed in [block 1](https://www.spacescan.io/block/1), at signage point `7`. +This hash is the genesis challenge for Chia's mainnet. This hash is the genesis challenge for Chia's mainnet. The complete JSON data for the genesis challenge is located [here](https://download.chia.net/notify/mainnet_alert.txt). The first block on Chia's mainnet ([block 0](https://www.spacescan.io/block/0)) was created at signage point `2`; it points to the genesis challenge as its previous block. The prefarm was then distributed in [block 1](https://www.spacescan.io/block/1), at signage point `7`. The first block on Chia's mainnet ([block 0](https://www.spacescan.io/block/0)) was created at signage point `2`; it points to the genesis challenge as its previous block. The prefarm was then distributed in [block 1](https://www.spacescan.io/block/1), at signage point `7`. The genesis challenge for other networks can be found opening `config.yaml` (located in `~/.chia/mainnet/config` for Chia's mainnet and testnets) and searching for `GENESIS_CHALLENGE:` in the section corresponding to the desired network. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/consensus-intro.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/consensus-intro.md index 6ee2bb566e..d2a9e9fa78 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/consensus-intro.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/consensus-intro.md @@ -3,6 +3,12 @@ title: Consensus Introduction slug: /consensus-intro --- +:::info + +This section is meant to provide a high level overview of Chia's consensus. If you are interested in implementing a new full node, we recommend that you review the [source code](https://github.com/Chia-Network/chia-blockchain/tree/main/chia/consensus) in order to understand in depth how the consensus is implemented. If you have further questions, feel free to reach out to us on [Discord](https://discord.gg/chia). + +::: + Decentralized consensus algorithms require Sybil resistance, using a resource that is both cryptographically verifiable and scarce (not infinite). In previous blockchain systems, two different scarce resources have been used: computing power (Proof of Work) and staked money (Proof of Stake). Chia's Proof of Space and Time consensus uses storage capacity as the scarce resource. This comes much closer than previous systems to Satoshi's original ideal of "one CPU, one vote," where a _vote_ refers to a chance to win and validate a block, not an actual vote on-chain. For example, someone storing 500 GiB has 5 "votes," and someone storing 100 GiB has 1 "vote." diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/foliage.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/foliage.md index bee6ae458e..7bf98d4214 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/foliage.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/foliage.md @@ -3,21 +3,31 @@ title: Foliage slug: /consensus-foliage --- -In the previous diagrams, there is no place for farmers to specify their rewards, since all blocks are canonical. There is also no place to include transactions. Everything we have talked about so far is the trunk of the blockchain. +In the previous diagrams, there is no place for farmers to specify their rewards, since all blocks are canonical. There is also no place to include transactions. Everything we have talked about so far is known as the _trunk_ of the blockchain. -Farmers have no say in how their block is constructed in the trunk, since they must use the exact proof of space, VDFs, and signatures that are specified. In order to include farming rewards, as well as transactions, in the system, we must introduce an additional component of blocks called _foliage_. +Farmers have no say in how their block is constructed in the trunk, since they must use the exact proof of space, VDFs, and signatures that are specified. In order to include farming rewards, as well as transactions, in the system, we must introduce an additional component to the reward chain called _foliage_. -**Trunk**: The component of blocks and the blockchain which includes VDFs, proofs of space, PoSpace signatures, challenges, and previous trunk blocks, and is completely canonical. The trunk never refers to the foliage chain. +**Trunk**: The component of blocks and the blockchain which includes VDFs, proofs of space, PoSpace signatures, challenges, and previous trunk blocks, and is completely canonical. The trunk includes each of the [three VDF chains](/three-vdf-chains), but it never refers to the foliage. -**Foliage**: The component of blocks and the blockchain which includes specification of where rewards should go, which transactions should be included, and what the previous foliage block is. This is up to the farmer to decide and is grindable, so it can never be used as input to the challenges. +**Foliage**: An extension of the blocks produced in the reward chain. A block's foliage includes the specification of where rewards should go, which transactions should be included, and what the previous block's foliage is. -**Re-org**: A re-org (or reorganization) is when a node's view of the peak changes, such that the old view contains a block that is not included in the new view (some block has been reversed). Both trunk and foliage re-orgs are possible, but should be rare in practice, and low in depth. +:::info + +Foliage provides a separation between the transactions and the consensus. + +A given block's farmer decides what is included in the foliage, thereby allowing the farmer to grind on its contents. If the transactions and the consensus were not separated, a farmer could grind on the foliage in order to gain an unfair edge in the consensus, which would allow them to win more blocks. For this reason, the foliage is kept separate from the consensus, and it can never be used as input to the challenges. + +It is also important to note that in the implementation, when a farmer submits a block, the trunk and foliage are both submitted together -- the two pieces are not calculated and submitted at separate times. The reason we emphasize the separation of the transactions and the consensus is because the farmer may not modify a block's trunk, but retains total control over the foliage. + +::: + +**Re-org**: A re-org (or reorganization) is when a node's view of the peak changes, such that the old view contains a block that is not included in the new view (one or more blocks have either been removed, or have changed order). Both trunk and foliage re-orgs are possible, but should be rare in practice, and low in depth. -In figure 11 below we can see that the foliage is added to blocks to produce an additional chain. This foliage includes a hash of the previous foliage, a reward block hash, and a signature. These foliage pointers are separate from the trunk chain, and are not canonical. That is, farmers could theoretically create a foliage re-org where foliage is replaced, but the exact same trunk (proofs of space and time) are used. +In figure 11 below we can see that the foliage is added to the blocks formed in the reward chain. This foliage includes a hash of the previous foliage, a reward block hash, and a signature. These foliage pointers are separate from the trunk chain, and are not canonical. That is, farmers could theoretically create a foliage re-org where foliage is replaced, but the exact same trunk (proofs of space and time) are used. -To prevent a foliage re-org, honest farmers only create one foliage block per block. As soon as one honest farmer has added a foliage block, the foliage becomes impossible to re-org beyond that height with the same PoSpace, since that farmer will not sign again with the same PoSpace. +To prevent a foliage re-org, honest farmers only create one set of foliage per block. As soon as one honest farmer has added foliage to a block, the foliage becomes impossible to re-org beyond that height with the same PoSpace, since that farmer will not sign again with the same PoSpace. -Furthermore, blocks like B3, which come parallel with another foliage block (B2), do not have to sign the previous foliage block, since they do not necessarily have enough time to see it. +Furthermore, blocks like B3, which come parallel with the foliage of another block (B2), do not have to sign the previous block's foliage, since they do not necessarily have enough time to see it. :::info @@ -33,12 +43,12 @@ Blocks which have red pointers are also eligible to create transactions, and are In the diagram, sp3 comes before B2, (a transaction block, and the previous block of B3), so B3 cannot be a transaction block. -The red arrows provide security by burying foliage blocks, but the gray arrows do not. The purpose of the gray arrows is to maintain a linked list in the foliage, and to reduce complexity in implementations. However, blocks with gray arrows pointing to them do get buried in the next-next block. +The red arrows provide security by burying foliage, but the gray arrows do not. The purpose of the gray arrows is to maintain a linked list in the foliage, and to reduce complexity in implementations. However, foliages with gray arrows pointing to them do get buried in the next-next block.
drawing
-Figure 11: Foliage blocks and trunk blocks. Blocks B1, B2, and B4 have transactions and have red pointers (pointers to last block). Note that the start of the sub-slot is also a signage point. +Figure 11: Foliage and trunk blocks. Blocks B1, B2, and B4 have transactions and have red pointers (pointers to last block). Note that the start of the sub-slot is also a signage point.
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/forks.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/forks.md index 13a81c3f80..0105ad3c0a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/forks.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/forks.md @@ -3,7 +3,7 @@ title: Forks slug: /consensus-forks --- -The following table is a comprehensive list of all forks (planned and activated) on Chia's blockchain. It was last updated on 2023-09-10. +The following table is a comprehensive list of all forks (planned and activated) on Chia's blockchain. It was last updated on 2023-09-10. It was last updated on 2023-09-10. | Activation Block | Activation Date | Type | Build | Status | Description | | :--------------- | :-------------- | :--- | :---- | :---------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -11,4 +11,6 @@ The following table is a comprehensive list of all forks (planned and activated) | `3 630 000` | 2023-05-07 | Soft | 1.7.0 | Activated | [Restrict `AGG_SIG_UNSAFE` message](https://github.com/Chia-Network/post-mortem/blob/main/2023-05/2023-05-08-AGG_SIG_UNSAFE-can-mimic-AGG_SIG_ME-condition.md) | | `3 886 635` | 2023-07-01 | Soft | 1.8.0 | Activated | [CHIP-14](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0014.md) -- `ASSERT_BEFORE_*` conditions | | `4 510 000` | 2023-11-12 | Soft | 2.0.0 | Activated | [CHIP-11](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md) -- BLS/SECP CLVM Operators | -| `5 496 000` | 2024-06 | Hard | 2.1.0 | Released,
Not Activated | [CHIP-12](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0012.md) -- Decrease plot filter | +| `5 496 000` | 2024-06-13 | Hard | 2.1.0 | Activated | [CHIP-12](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0012.md) -- Decrease plot filter | +| `5 716 000` | 2024-07 | Soft | 2.3.0 | Released,
Not Activated | [CHIP-25](https://github.com/Chia-Network/chips/pull/98) -- Chialisp Message Conditions | +| `5 940 000` | 2024-09 | Soft | 2.4.0 | Released,
Not Activated | Disallow infinity G1 points | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/signage-and-infusion-points.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/signage-and-infusion-points.md index ce91f5321f..29b3338426 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/signage-and-infusion-points.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/consensus/signage-and-infusion-points.md @@ -11,7 +11,7 @@ The challenge and reward chains both have signage points. The infused challenge ::: -The signage points occur every 9.375 seconds (64 signage points per 600-second sub-slot). The number of iterations between each signage point is **sp_interval_iterations**, which is equal to sub-slot_iterations / 64. +The signage points occur every 9.375 seconds (64 signage points per 600-second sub-slot). The number of iterations between each signage point is **_sp_interval_iterations_**, which is equal to _sub-slot_iterations / 64_. The challenge at the start of the sub-slot is also a valid signage point. As each of the 64 signage points in the sub-slot is reached, those points are broadcast, starting from the fastest timelord's full node, and propagating to every other full node on the network. @@ -35,13 +35,13 @@ For both of our [previous example](/consensus-challenges), as well as the next e ::: -- sub-slot_iterations = 100,000,000 -- sp_interval_iterations = `sub-slot_iterations` / 64 = 1,562,500 +- _sub-slot_iterations = 100,000,000_ +- _sp_interval_iterations = `sub-slot_iterations` / 64 = 1,562,500_ -The farmer computes the **required_iterations** for each proof of space. If the required_iterations < sp_interval_iterations, the proof of space is eligible for inclusion into the blockchain. At this point, the farmer fetches the entire proof of space from disk (which requires 64 disk seeks, or 640 ms on a slow HDD), creates an unfinished block, and broadcasts it to the network. +The farmer computes the **required_iterations** for each proof of space. If the required*iterations < sp_interval_iterations, the proof of space is eligible for inclusion into the blockchain. At this point, the farmer fetches the entire proof of space from disk (which requires 64 disk seeks, or 640 ms on a slow HDD), creates an unfinished block, and broadcasts it to the network. If the \_required_iterations < sp_interval_iterations*, the proof of space is eligible for inclusion into the blockchain. At this point, the farmer fetches the entire proof of space from disk (which requires 64 disk seeks, or 640 ms on a slow HDD), creates an unfinished block, and broadcasts it to the network. :::info -For the vast majority of eligible plots, required_iterations will be far too high, since on average 32 will qualify for the whole network for each 10-minute sub-slot. This is a random process so it's possible (though unlikely) for a large number of proofs to qualify. The signage_point_iterations is the number of iterations from the start of the sub-slot to the signage point. Any plot that does meet the required_iterations for a signage point will qualify as there is no rivalry between winning plots. +For the vast majority of eligible plots, _required_iterations_ will be far too high, since on average 32 will qualify for the whole network for each 10-minute sub-slot. This is a random process so it's possible (though unlikely) for a large number of proofs to qualify. Any plot that does meet the _required_iterations_ for a signage point will qualify as there is no rivalry between winning plots. ::: The exact method for required_iterations is the following: @@ -54,17 +54,19 @@ required_iterations = (difficulty // pow(2, 256) * expected_plot_size(size)) ``` -The difficulty constant factor is based on the initial constants of the blockchain. For Chia, it is `2^67`. The difficulty varies per epoch, as explained in the [Epoch and Difficulty page](/epoch-and-difficulty). As you can see, the **sp_quality_string** is converted into a random number between 0 and 1, by dividing it by `2^256`, and then multiplied by the plot size. +The difficulty constant factor is based on the initial constants of the blockchain. For Chia, it is _2^67_. The difficulty varies per epoch, as explained in [Section 3.11](/epoch-and-difficulty) 'Section 3.11: Epochs and Difficulty Adjustment'). As you can see, the `sp_quality_string` is converted into a random number between 0 and 1, by dividing it by _2^256_, and then multiplied by the plot size. -For consensus purposes, the `expected_plot_size` is `((2 * k) + 1) * (2 ** (k - 1)).`, where k>=32\<50. The actual plot size is that value times a constant factor, in bytes. This is because each entry in the plot is around `k+0.5` bits, and there are around `2^(k)` entries. +For consensus purposes, the `expected_plot_size` is `((2 * k) + 1) * (2 ** (k - 1)).`, where k>=32\<50. The actual plot size is that value times a constant factor, in bytes. This is because each entry in the plot is around `k+0.5` bits, and there are around `2^(k)` entries. The actual plot size is that value times a constant factor, in bytes. This is because each entry in the plot is around `k+0.5` bits, and there are around `2 ** k` entries. -The **infusion_iterations** is the number of iterations from the start of the sub-slot at which the block with at least the required quality can be included into the blockchain. This is calculated as: +The _signage_point_iterations_ is the number of iterations from the start of the sub-slot to the signage point. + +The **infusion_iterations** is the number of iterations from the start of the sub-slot at which the block with at least the required quality can be included into the blockchain. This is calculated as: This is calculated as: ``` infusion_iterations = ( signage_point_iterations + 3 * sp_interval_iterations + required_iterations) % sub-slot_iterations ``` -Therefore, infusion_iterations will be between 3 and 4 signage points after the current signage point. Farmers must submit their proofs and blocks before the infusion point is reached. The modulus is there to allow overflows into the next sub-slot, if the signage point is near the end of the sub-slot. This is expanded on in the [Overflow Blocks and Weight page](/overflow-blocks). +Therefore, _infusion_iterations_ will be between 3 and 4 signage points after the current signage point. Farmers must submit their proofs and blocks before the infusion point is reached. The modulus is there to allow overflows into the next sub-slot, if the signage point is near the end of the sub-slot. This is expanded on in [Section 3.9](/overflow-blocks) 'Section 3.9: Overflow Blocks and Weight'). :::info More information on infusion points is available in the [VDFs page](/proof-of-time#infusion). @@ -81,41 +83,37 @@ Figure 5 shows the infusion point as a green square marked `b1`. The first and l At `b1`, the farmer's block gets combined with the VDF output for that point. This creates a new input for the VDF from that point on, i.e. we infuse the farmer's block into the VDF. `b1` is only fully valid after two events have occurred: -1. infusion_iterations has been reached, and -2. Two VDF proofs have been included: one from `r1` to the signage point and one from `r1` to `b1`. (Actually it's more since there are three VDF chains, explained in the [Three VDF Chains page](/three-vdf-chains)). +1. _infusion_iterations_ has been reached, and +2. Two VDF proofs have been included: one from `r1` to the signage point and one from `r1` to `b1`. (Actually it's more since there are three VDF chains, explained in [Section 3.8](/three-vdf-chains) 'Section 3.8: Three VDF Chains')). -In Figure 5, the farmer creates the block at the time of the signage point, `b1'`. However, `b1'` is not finished yet, since it needs the infusion point VDF. Once the infusion_iterations VDF has been released, it is added to `b1'` to form the finished block at `b1`. +In Figure 5, the farmer creates the block at the time of the signage point, `b1'`. However, `b1'` is not finished yet, since it needs the infusion point VDF. Once the _infusion_iterations_ VDF has been released, it is added to `b1'` to form the finished block at `b1`. Recall that in this example, -- sub-slot_iterations = 100M -- sp_interval_iterations is 1.5625M. Furthermore, let's say a farmer has a total of 1000 plots. +- _sub-slot_iterations = 100,000,000_ +- _= (signage \* point \* sp \* interval_iterations) + (3 \* sp_interval_iterations) + required_iterations_ -For each of the 64 signage points, as they are released to the network every 9.375 seconds, or every 1.5625M iterations, the farmer computes the plot filter and sees how many plots pass. For each passing plot, the farmer calculates required_iterations. +For each of the 64 signage points, as they are released to the network every 9.375 seconds, or every 1.5625M iterations, the farmer computes the plot filter and sees how many plots pass. For each passing plot, the farmer calculates required*iterations. For each passing plot, the farmer calculates \_required_iterations*. -Let's say the farmer calculates required_iterations < 1.5625M once in the sub-slot. (We'll assume the exact required_iterations = 0.7828M in this instance.) Figure 5 shows this happening at the 20th signage point. +Let's say the farmer calculates required*iterations < 1.5625M once in the sub-slot. (We'll assume the exact required_iterations = 0.7828M in this instance.) Figure 5 shows this happening at the 20th signage point. (We'll assume the exact \_required_iterations = 782,800* in this instance.) Figure 5 shows this happening at the 20th signage point. infusion_iterations is then computed as: +``` infusion_iterations = signage_point_iterations + (3 \* sp_interval_iterations) + required_iterations +``` -= (signage \* point \* sp \* interval_iterations) + (3 \* sp_interval_iterations) + required_iterations - -= (20 \* 1.5625M) + (3 \* 1.5626M) + 0.7827M - -= 36.7223M - -After realizing they have won (at the 20th infusion point), the farmer fetches the whole proof of space, makes a block (optionally including transactions), and broadcasts this to the network. The block has until infusion_iterations (typically a few seconds) to reach timelords, who will infuse the block, creating the infusion point VDFs. With these VDFs, the block can be finished and added to the blockchain by full nodes. +After realizing they have won (at the 20th infusion point), the farmer fetches the whole proof of space, makes a block (optionally including transactions), and broadcasts this to the network. The block has until _infusion_iterations_ (typically a few seconds) to reach timelords, who will infuse the block, creating the infusion point VDFs. With these VDFs, the block can be finished and added to the blockchain by full nodes. ## Rationale for choosing 64 signage points -Chia's original consensus, which was phased out before the launch of mainnet, used a single signage point per 10-minute subslot. This left the network vulnerable to short-range [replotting attacks](/consensus-attacks#replotting), where an attacker initiates a plot's creation after a signage point, and completes the plot before the next infusion point. The attacker could always choose a plot that passes the plot filter (because the signage point is hashed with the subslot challenge and the plot ID in calculating the filter) and then delete the plot after the infusion point. For a 512-filter, this would result in the attacker mimicking 512 plots (~51 TiB). In reality, under the original consensus, he or she would only need to own single computer capable of creating a plot in less than ten minutes. +Chia's original consensus, which was phased out before the launch of mainnet, used a single signage point per 10-minute subslot. This left the network vulnerable to short-range [replotting attacks](/consensus-attacks#replotting), where an attacker initiates a plot's creation after a signage point, and completes the plot before the next infusion point. The attacker could always choose a plot that passes the plot filter (because the signage point is hashed with the subslot challenge and the plot ID in calculating the filter) and then delete the plot after the infusion point. For a 512-filter, this would result in the attacker mimicking 512 plots (~51 TiB). In reality, under the original consensus, they would only need to own single computer capable of creating a plot in less than ten minutes. :::note Technically this isn't an _attack_ because -- even if successful -- the "attacker" wouldn't gain an ability to cheat the network. However the "attacker" _would_ be using the network in an unintended way, effectively turning Chia into a Proof of Work system. Therefore, Chia's new consensus was intentionally designed to discourage this behavior. ::: -The new consensus was introduced during Chia's beta phase. One of the modifications was to increase the number of signage points to 64 per 10-minute subslot, or one every 9.375 (600/64) seconds, on average. The Challenge Chain was also introduced (see the [Three VDF Chains page](/three-vdf-chains) for more info). The maximum distance between a signage point and the next infusion point is now 4 signage points (see the `infusion_iterations` formula, above), or 37.5 seconds. This is the maximum amount of time for the attack to be possible, but for it to be consistently applied, the minimum time of 28.125 seconds must be applied. Assuming a few extra seconds for network latency and other factors, the attack is now only possible if one can create a new plot in less than 25 seconds. +The new consensus was introduced during Chia's beta phase. One of the modifications was to increase the number of signage points to 64 per 10-minute subslot, or one every 9.375 (600/64) seconds, on average. The Challenge Chain was also introduced (see the [Three VDF Chains page](/three-vdf-chains) for more info). The maximum distance between a signage point and the next infusion point is now 4 signage points (see the _infusion_iterations_ formula, above), or 37.5 seconds. This is the maximum amount of time for the attack to be possible, but for it to be consistently applied, the minimum time of 28.125 seconds must be applied. Assuming a few extra seconds for network latency and other factors, the attack is now only possible if one can create a new plot in less than 25 seconds. :::note Keep in mind that this "attack" is really mimicking the ownership of around 51 TiB of storage. Even when it does become possible to run the attack consistently, it will likely be much cheaper to use the network as intended, storing plots on non-volatile storage. @@ -127,14 +125,14 @@ This begs the question: why not use even more signage points in the consensus? T **Quality string**: A small part of the proof of space, 2 _x values_ out of the total 64 _x values_, which can be retrieved efficiently from disk, and which values_to_fetch is determined by the signage point. -**sp_quality_string**: A hash of the quality string concatenated with the challenge chain's signage point. This hash is what ultimately decides the "luck" of a certain proof, using the size of required_iterations. +**sp_quality_string**: A hash of the quality string concatenated with the challenge chain's signage point. This hash is what ultimately decides the "luck" of a certain proof, using the size of required*iterations. This hash is what ultimately decides the "luck" of a certain proof, using the size of \_required_iterations* **sp_interval_iterations**: Defined as floor(sub-slot_iterations / 64). **Signage points**: 64 intermediary points in time within a sub-slot in both the challenge and reward chains, for which VDFs are periodically released. At each signage point, a VDF output is created and broadcast through the network. The first signage point in the sub-slot is the challenge itself. Each block has a signage point such that the proof of space in the block must be eligible for that signage point. -**required_iterations**: A number computed using the quality string, used to choose proofs of space which are eligible to make blocks. The vast majority of proofs of space will have required_iterations which are too high, and thus not eligible for inclusion into the chain. This number is used to compute the infusion point. +**required_iterations**: A number computed using the quality string, used to choose proofs of space which are eligible to make blocks. The vast majority of proofs of space will have required*iterations which are too high, and thus not eligible for inclusion into the chain. This number is used to compute the infusion point. The vast majority of proofs of space will have \_required_iterations* which are too high, and thus not eligible for inclusion into the chain. This number is used to compute the infusion point. -**Infusion point**: The point in time at infusion_iterations from the challenge point, for a proof of space with a certain challenge and infusion_iterations. At this point, the farmer's block gets infused into the reward chain VDF. The infusion point of a block is always between 3 and 4 signage points after the signage point of that block. Computed as signage_point_iterations + 3 \* sp_interval_iterations + required_iterations. +**Infusion point**: The point in time at infusion*iterations from the challenge point, for a proof of space with a certain challenge and infusion_iterations. At this point, the farmer's block gets infused into the reward chain VDF. The infusion point of a block is always between 3 and 4 signage points after the signage point of that block. Computed as signage_point_iterations + 3 \* sp_interval_iterations + required_iterations. At this point, the farmer's block gets infused into the reward chain VDF. The infusion point of a block is always between 3 and 4 signage points after the signage point of that block. Computed as \_signage_point_iterations + 3 \* sp_interval_iterations + required_iterations*. The delay between the signage point and infusion point has many benefits, including defense against orphaning and selfish farming, decreased forks, and no VDF pauses. This delay of around 28 seconds is given so that farmers have enough time to sign without delaying the slot VDF. Well-behaving farmers sign only one signage point with each proof of space, meaning that attackers cannot easily reorg the chain. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/contribution/using-github.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/contribution/using-github.md new file mode 100644 index 0000000000..2f1652f485 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/contribution/using-github.md @@ -0,0 +1,243 @@ +--- +title: Using Github for Chia Contributions +slug: /contribution/using-github +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +import ForkButton from '@site/static/img/contributing/fork-button.webp'; +import CodeButton from '@site/static/img/contributing/code-button.webp'; +import AddGPG from '@site/static/img/contributing/userbar-account-settings-global-nav-update.webp'; + +## Using GitHub + +We use Github for source code control, the two main ways to interact with Github are via the web browser or via cli commands, the below links are focused on the web browser access. + +### Create a Github Account + +:::info +The below information has been copied from the [Github docs](https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github). +::: + +To get started with GitHub, you'll need to create a free personal account on GitHub.com and verify your email address. + +Every person who uses GitHub.com signs in to a personal account. Your personal account is your identity on GitHub.com and has a username and profile. For example, see [@octocat's profile](https://github.com/octocat). + +Later, you can explore the different types of accounts that GitHub offers, and decide if you need a billing plan. For more information, see ["Types of GitHub accounts"](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts) and ["GitHub’s plans"](https://docs.github.com/en/get-started/learning-about-github/githubs-plans). + +#### Signing up for a Personal Account + +1. Navigate to https://github.com/. +2. Click Sign up. +3. Follow the prompts to create your personal account. + +During sign up, you'll be asked to verify your email address. Without a verified email address, you won't be able to complete some basic GitHub tasks, such as creating a repository. + +If you're having problems verifying your email address, there are some troubleshooting steps you can take. For more information, see ["Verifying your email address"](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/verifying-your-email-address#troubleshooting-email-verification). + +--- + +### Installing Github Desktop + +:::info +The below information has been adapted from the [Github docs](https://docs.github.com/en/desktop/installing-and-authenticating-to-github-desktop/installing-github-desktop). +::: + +You can install GitHub Desktop on Windows 10 64-bit or later. + +:::warning +You must have a 64-bit operating system to run GitHub Desktop. +::: + +1. Visit the [download page for GitHub Desktop](https://desktop.github.com/). +2. Click Download for Windows. +3. In your computer's Downloads folder, double-click the GitHub Desktop setup file. +4. GitHub Desktop will launch after installation is complete. + +--- + +### Forking a Repository + +:::info +The below information has been adapted from the [Github docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo). +::: + +A fork is a new repository that shares code and visibility settings with the original “upstream” repository. The below example is for the chia-docs repo but the same process can be followed for any of the public Chia-Network repos. + +1. On GitHub.com, navigate to the [Chia-Network/chia-docs](https://github.com/Chia-Network/chia-docs) repository. +2. In the top-right corner of the page, click Fork. + +
+ Fork a Repository in Github +
+
+ +3. Under "Owner," select the dropdown menu and click an owner for the forked repository. +4. By default, forks are named the same as their upstream repositories. Optionally, to further distinguish your fork, in the "Repository name" field, type a name. +5. Optionally, in the "Description" field, type a description of your fork. +6. Optionally, select **Copy the DEFAULT branch only**. + For many forking scenarios, such as contributing to open-source projects, you only need to copy the default branch. If you do not select this option, all branches will be copied into the new fork. +7. Click **Create fork**. + +:::note +If you want to copy additional branches from the upstream repository, you can do so from the Branches page. For more information, see ["Creating and deleting branches within your repository"](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository). +::: + +#### Cloning a Forked Repository + +:::info +The below information has been adapted from the [Github docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo?tool=webui#cloning-your-forked-repository). +::: + +Right now, you have a fork of the chia-docs repository, but you do not have the files in that repository locally on your computer. + +1. On GitHub.com, navigate to your fork of the Chia-Network/chia-docs repository. +2. Above the list of files, click **Code**. + +
+ Clone a Repository in Github +
+
+ +3. Click "Open with Github Desktop" (this clones the repo locally where you can edit it) + +--- + +### Setup Commit Signing + +All Chia related Github repos require the signing of commits, follow the outlined process to setup automated commit signing for the Github Desktop Application. + +#### Generating a New GPG Key + +:::info +The below information has been adapted from the [Github docs](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key). +::: + +:::note +Note: Before generating a new GPG key, make sure you've verified your email address. If you haven't verified your email address, you won't be able to sign commits and tags with GPG. For more information, see ["Verifying your email address"](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/verifying-your-email-address). +::: + +1. Download and install [the GPG command line tools](https://www.gnupg.org/download/) for your operating system. We generally recommend installing the latest version for your operating system. + +2. Open Git Bash. + +3. Generate a GPG key pair. Since there are multiple versions of GPG, you may need to consult the relevant [man page](https://en.wikipedia.org/wiki/Man_page) to find the appropriate key generation command. + + - If you are on version 2.1.17 or greater, paste the text below to generate a GPG key pair. + + ```shell + gpg --full-generate-key + ``` + + - If you are not on version 2.1.17 or greater, the gpg --full-generate-key command doesn't work. Paste the text below and skip to step 6. + + ```shell + gpg --default-new-key-algo rsa4096 --gen-key + ``` + +4. At the prompt, specify the kind of key you want, or press `Enter` to accept the default. + +5. At the prompt, specify the key size you want, or press `Enter` to accept the default. + +6. Enter the length of time the key should be valid. Press `Enter` to specify the default selection, indicating that the key doesn't expire. Unless you require an expiration date, we recommend accepting this default. + +7. Verify that your selections are correct. + +8. Enter your user ID information. + :::note + When asked to enter your email address, ensure that you enter the verified email address for your GitHub account. To keep your email address private, use your GitHub-provided no-reply email address. For more information, see "Verifying your email address" and "Setting your commit email address." + ::: + +9. Type a secure passphrase. + +10. Use the `gpg --list-secret-keys --keyid-format=long` command to list the long form of the GPG keys for which you have both a public and private key. A private key is required for signing commits or tags. + +```shell + gpg --list-secret-keys --keyid-format=long +``` + +:::note +Some GPG installations on Linux may require you to use `gpg2 --list-keys --keyid-format` LONG to view a list of your existing keys instead. In this case you will also need to configure Git to use gpg2 by running `git config --global gpg.program gpg2`. +::: + +11. From the list of GPG keys, copy the long form of the GPG key ID you'd like to use. In this example, the GPG key ID is `3AA5C34371567BD2`: + +```shell + $ gpg --list-secret-keys --keyid-format=long + /Users/hubot/.gnupg/secring.gpg + ------------------------------------ + sec 4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10] + uid Hubot + ssb 4096R/4BB6D45482678BE3 2016-03-10 +``` + +12. Paste the text below, substituting in the GPG key ID you'd like to use. In this example, the GPG key ID is `3AA5C34371567BD2`: + +``` + gpg --armor --export 3AA5C34371567BD2 + # Prints the GPG key ID, in ASCII armor format +``` + +13. Copy your GPG key, beginning with `-----BEGIN PGP PUBLIC KEY BLOCK-----` and ending with `-----END PGP PUBLIC KEY BLOCK-----`. +14. [Add the GPG key to your GitHub account](https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account). + +#### Configure Git to Sign Commits by Default + +``` +- open Git Bash and run `git config --global commit.gpgsign true` +``` + +#### Store your GPG Key Passphrase + +:::info +Storing your passphrase ensures you don't have to enter it every time you want to sign a commit, this is strictly optional. +::: + +- For Mac users, the [GPG Suite](https://gpgtools.org/) allows you to store your GPG key passphrase in the macOS Keychain. +- For Windows users, the [Gpg4win](https://www.gpg4win.org/) integrates with other Windows tools. +- You can also manually configure [gpg-agent](http://linux.die.net/man/1/gpg-agent) to save your GPG key passphrase, but this doesn't integrate with macOS Keychain like ssh-agent and requires more setup. + +#### Add a GPG Key to Your GitHub Account + +:::info +The below information has been adapted from the [Github docs](https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account). +::: + +1. In the upper-right corner of any page, click your profile photo, then click `Settings`. + +
+ Add a GPG Key to Your Github Account +
+
+ +2. In the "Access" section of the sidebar, click **SSH and GPG keys**. +3. Next to the "GPG keys" header, click **New GPG key**. +4. In the "Title" field, type a name for your GPG key. +5. In the "Key" field, paste the GPG key you copied when you [generated your GPG key](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key). +6. Click **Add GPG key**. +7. To confirm the action, authenticate to your GitHub account. + +--- + +### Making a Pull Request + +:::info +The below information has been adapted from the [Github docs](https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project#making-a-pull-request). +::: + +At last, you're ready to propose changes into the main project! This is the final step in producing a fork of someone else's project, and arguably the most important. If you've made a change that you feel would benefit the community as a whole, you should definitely consider contributing back. + +1. To do so, head on over to the repository on GitHub where your project lives. For this example, it would be at `https://github.com//chia-docs`. +2. You'll see a banner indicating that your branch is one commit ahead of chia-docs:main. Click **Contribute** and then **Open a pull request**. +3. GitHub will bring you to a page that shows the differences between your fork and the Chia-Network/chia-docs repository. Click **Create pull request**. + - GitHub will bring you to a page where you can enter a title and a description of your changes. It's important to provide as much useful information and a rationale for why you're making this pull request in the first place. The project owner needs to be able to determine whether your change is as useful to everyone as you think it is. +4. Finally, click **Create pull request**. + +--- + +## Contribution support + +Join Our [Discord](https://discord.gg/chia) and jump into the #support channel for support. + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/dev-guides-home.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/dev-guides-home.md index bea0c87fae..cfbce03c75 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/dev-guides-home.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/dev-guides-home.md @@ -52,114 +52,70 @@ Embark on a swift journey into Chia Network's Crash Course for developers. Start
-
-
- Intro to Developing on Chia + +
+
+ Intro to Developing on Chia +
-
- - - -
-
+
-
-
- Intro to Chialisp -
-
-
-
-
-
- Intro to Smart Coins -
-
-
-
-
-
- Intro to Signatures -
-
-
-
-
-
- Intro to State -
-
- - - + +
+
+ Intro to State +
-
+
-
-
- Intro to Inner Puzzles -
-
-
-
-
-
- Intro to Cats, Offers, and NFTs -
-
-
-
-
-
- Chialisp and Typescript + +
+
+ Chialisp and Typescript +
-
- - - -
-
+
@@ -175,100 +131,79 @@ Explore the core building blocks of Chia development in the Primitives section.
-
-
- NFTs + +
+
+ NFTs +
-
- - - -
-
+
-
-
- CATs -
-
- - - + +
+
+ CATs +
-
+
-
-
- DataLayer™ -
-
- - - + +
+
+ DataLayer™ +
-
+
-
-
- Clawback + +
+
+ Clawback +
-
- - - -
-
+
-
-
- Offers + +
+
+ Offers +
-
- - - -
-
+
-
-
- DAOs + +
+
+ DAOs +
-
- - - -
-
+
-
-
- Verifiable Credentials -
-
- - - + +
+
+ Verifiable Credentials +
-
+
@@ -284,101 +219,64 @@ Immerse yourself in Chia Network's Tutorials section for developers. Understand
-
-
- Application Structure + +
+
+ Application Structure +
-
- - - -
-
+
-
-
- Custom Puzzle Lock -
-
-
-
-
-
- Custody Tool + +
+
+ Custody Tool +
-
- - - -
-
+
-
-
- RPC Coin Spend -
-
-
-
-
-
- Seeder User Guide -
-
- - - + +
+
+ Seeder User Guide +
-
+
-
-
- Simulator User Guide -
-
-
-
-
-
- WalletConnect -
-
-
-
@@ -393,157 +291,100 @@ Dive into the Video Series of Chia Network's Developer Guides for a dynamic lear
-
-
- Why Chia is Great -
-
-
-
-
-
- Developing Chia Applications -
-
-
-
-
-
- Tools and Setup + +
+
+ Tools and Setup +
-
- - - -
-
+
-
-
- Programming in ChiaLisp -
-
- - - + +
+
+ Programming in ChiaLisp +
-
+
-
-
- Coin Lifecycle -
-
-
-
-
-
- Singleton Contracts -
-
- - - + +
+
+ Singleton Contracts +
-
+
-
-
- State, Coins, and Announcements -
-
-
-
-
-
- Security, Arguments, and Signing + +
+
+ Security, Arguments, and Signing +
-
- - - -
-
+
-
-
- Announcements and Oracles -
-
- - - + +
+
+ Announcements and Oracles +
-
+
-
-
- Single Issuance CATs -
-
-
-
-
-
- Multiple Issuance CATs -
-
-
-
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/docs-home.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/docs-home.md index 130aae18c8..e8155c8fb8 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/docs-home.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/docs-home.md @@ -47,58 +47,38 @@ Embark on your Chia Network journey with our Beginner Documentation! Uncover the
-
-
- Intro to Chia + +
+
+ Intro to Chia +
-
- - - -
-
+
-
-
- Beginners Farming Guide -
-
-
-
-
-
- Beginners Wallet Guide -
-
-
-
-
-
- Using the GUI -
-
- - - + +
+
+ Using the GUI +
-
+
@@ -114,115 +94,95 @@ Explore the advanced features of Chia Network through our comprehensive document
-
-
- Advanced Installation + +
+
+ Advanced Installation +
-
- - - -
-
+
-
-
- Testnets -
-
- - - + +
+
+ Testnets +
-
+
-
-
- Plotting Deep Dive + +
+
+ Plotting Deep Dive +
-
- - - -
-
+
-
-
- Farming Deep Dive -
-
+ + + + + + + + + + + +
-
-
-
-
- Reference Client Deep Dive + +
+
+ Reference Client Deep Dive +
-
- - - -
-
+
-
-
- RPC Reference + +
+
+ RPC Reference +
-
- - - -
-
+
-
-
- CLI Reference + +
+
+ CLI Reference +
-
- - - -
-
+
-
-
- WalletConnect Reference -
-
-
-
@@ -237,44 +197,31 @@ Navigate Chia Network's Troubleshooting Documentation with precision. Check the
-
-
- Check if Things are Working -
-
- - - + +
+
+ Check if Things are Working +
-
+
-
-
- Node Syncing -
-
-
-
-
-
- Logging Reference + +
+
+ Logging Reference +
-
- - - -
-
+
@@ -290,100 +237,71 @@ Embark on a knowledge journey through Chia Network's Learn documentation. Delve
-
-
- CoinSet Model + +
+
+ CoinSet Model +
-
- - - -
-
+
-
-
- Architecture + +
+
+ Architecture +
-
- - - -
-
+
-
-
- Blockchain Consensus -
-
- - - + +
+
+ Blockchain Consensus +
-
+
-
-
- Chia Keys -
-
-
-
-
-
- Protocol -
-
- - - + +
+
+ Protocol +
-
+
-
-
- Green Paper -
-
-
-
-
-
- Resources + +
+
+ Resources +
-
- - - -
-
+
@@ -399,44 +317,35 @@ Dive into Chia Network's Developer Guides for an immersive experience. Begin wit
-
-
- Chia Crash Course + +
+
+ Chia Crash Course +
-
- - - -
-
+
-
-
- Primitives + +
+
+ Primitives +
-
- - - -
-
+
-
-
- Tutorials -
-
- - - + +
+
+ Tutorials +
-
+
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/checking-farm-health.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/checking-farm-health.md index d1c64e337b..efb8c501f2 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/checking-farm-health.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/checking-farm-health.md @@ -5,9 +5,9 @@ slug: /checking-farm-health > "Is my farm working?" -It's one of the most common questions farmers ask themselves. This is understandable -- it is possible for those with small- and medium-size farms to go weeks or months without winning a block reward, even if everything is working properly. +It's one of the most common questions farmers ask themselves. It's one of the most common questions farmers ask themselves. This is understandable -- it is possible for those with small- and medium-size farms to go weeks or months without winning a block reward, even if everything is working properly. -The easiest mitigation against this anxiety is to [join a pool](/pool-farming). Your pool will occasionally send you partial challenges in order to estimate your farm's size. If everything is working properly, your pool will report a size for your farm that comes close to its actual size. +The easiest mitigation against this anxiety is to [join a pool](/pool-farming). Your pool will occasionally send you partial challenges in order to estimate your farm's size. If everything is working properly, your pool will report a size for your farm that comes close to its actual size. Your pool will occasionally send you partial challenges in order to estimate your farm's size. If everything is working properly, your pool will report a size for your farm that comes close to its actual size. Beyond joining a pool, there are a few other things you can do to make sure your farm is working properly, whether you use the GUI or the CLI. @@ -28,32 +28,32 @@ Here is how to interpret each of the statistics in the above image: #### Farm Health - **Sync status** -- Shows whether your full node is synced. -- **Plots passing filter** -- Shows whether the "correct" number of plots are passing the [plot filter](https://help.chia.net/hc/en-us/articles/8373437367191-What-is-the-plot-filter-and-why-didn-t-my-plot-pass-it-). The popup, as shown in the above image, contains several stats. As long as the numbers next to `Total plots passing filter` and `Expected Total plots passing filter` are similar, this aspect of your farm is working properly. -- **Missing signage points** -- Chia's consensus is designed such that 64 [signage points](/signage-and-infusion-points) are broadcast every 10 minutes, or 9216 signage points per day. You are ineligible to win a block at any missed signage points. It is normal to miss a few signage points per day, for example due to a temporary outage in your local network. However, if you miss 100 or more signage points per day, there is likely something wrong. The two most common causes for this are that your harvester is overwhelmed (fix this by moving some HDDs to another harvester), or that your network is experiencing frequent outages. -- **Stale partials** -- Your pool will send partial challenges to your node in order to estimate how much space you are contributing. If your node doesn't respond to a partial challenge quickly, it will be considered "stale". Just as with missing signage points, an occasional stale partial is nothing to worry about. If you experience a frequent number of stale partials, the causes and solutions tend to be the same as with missing signage points. +- **Plots passing filter** -- Shows whether the "correct" number of plots are passing the [plot filter](https://help.chia.net/hc/en-us/articles/8373437367191-What-is-the-plot-filter-and-why-didn-t-my-plot-pass-it-). The popup, as shown in the above image, contains several stats. As long as the numbers next to `Total plots passing filter` and `Expected Total plots passing filter` are similar, this aspect of your farm is working properly. The popup, as shown in the above image, contains several stats. As long as the numbers next to `Total plots passing filter` and `Expected Total plots passing filter` are similar, this aspect of your farm is working properly. +- **Missing signage points** -- Chia's consensus is designed such that 64 [signage points](/signage-and-infusion-points) are broadcast every 10 minutes, or 9216 signage points per day. You are ineligible to win a block at any missed signage points. It is normal to miss a few signage points per day, for example due to a temporary outage in your local network. However, if you miss 100 or more signage points per day, there is likely something wrong. The two most common causes for this are that your harvester is overwhelmed (fix this by moving some HDDs to another harvester), or that your network is experiencing frequent outages. You are ineligible to win a block at any missed signage points. It is normal to miss a few signage points per day, for example due to a temporary outage in your local network. However, if you miss 100 or more signage points per day, there is likely something wrong. The two most common causes for this are that your harvester is overwhelmed (fix this by moving some HDDs to another harvester), or that your network is experiencing frequent outages. +- **Stale partials** -- Your pool will send partial challenges to your node in order to estimate how much space you are contributing. If your node doesn't respond to a partial challenge quickly, it will be considered "stale". Just as with missing signage points, an occasional stale partial is nothing to worry about. If you experience a frequent number of stale partials, the causes and solutions tend to be the same as with missing signage points. If your node doesn't respond to a partial challenge quickly, it will be considered "stale". Just as with missing signage points, an occasional stale partial is nothing to worry about. If you experience a frequent number of stale partials, the causes and solutions tend to be the same as with missing signage points. #### Netspace - **Total Netspace** -- This shows an estimate of the total amount of space on Chia's entire network. -- **Farming Space** -- This is hidden behind the popup dialog in the above image. It is your local node's contribution of space to the network. +- **Farming Space** -- This is hidden behind the popup dialog in the above image. It is your local node's contribution of space to the network. It is your local node's contribution of space to the network. #### Farming Rewards - **Estimated Time to Win** -- This is only an estimation of when you will create your next block, based on the percentage of the total netspace you are contributing. You have a 50% chance of winning sooner than this, and a 50% chance of winning later. It is not uncommon for 5x this amount of time to elapse between block wins, even if your farm is set up perfectly. Also keep in mind that the probability that you will win the next block does not increase as more time elapses. The Gambler's Fallacy applies here. -- **Estimated daily XCH** -- The formula for this is `(1 day / Estimated Time to Win) * block reward`. If you join a pool, this is roughly how much you should receive each day. However, you need to account for pool fees, as well as the fact that 1/8 of the reward goes directly to the farmer. +- **Estimated daily XCH** -- The formula for this is `(1 day / Estimated Time to Win) * block reward`. If you join a pool, this is roughly how much you should receive each day. However, you need to account for pool fees, as well as the fact that 1/8 of the reward goes directly to the farmer. If you join a pool, this is roughly how much you should receive each day. However, you need to account for pool fees, as well as the fact that 1/8 of the reward goes directly to the farmer. - **Estimated monthly XCH** -- Same as above, but taken as a monthly estimate. #### Pooling Health -- **Valid Partials** -- Partial proofs your node has successfully returned to your pool, expressed as both a number and a percentage. See above for more info on partials. +- **Valid Partials** -- Partial proofs your node has successfully returned to your pool, expressed as both a number and a percentage. See above for more info on partials. See above for more info on partials. - **Stale Partials** -- The percent and number of partials your node has failed to return on time. - **Invalid partials** -- The percent and number of partials your node has returned that were invalid. - **Missing partials** -- The percent and number of partials your node has failed to return. #### Last Attempted Proof -- **Plots Passed Filter** -- At each signage point, a certain number of your plots will pass the plot filter. The numerator indicates the number of plots that are eligible to play in that specific Proof of Space lottery. For small farms, this number is often 0. The denominator indicates your farm's total number of plots. -- **Proofs Found** -- The number of valid proofs found at that signage point. If you are not in a pool, a number greater than 0 indicates that you have successfully found a proof and will likely win a block reward at the next transaction block. If you are in a pool, a number greater than 0 likely means that a valid partial proof was found and will be returned to your pool. +- **Plots Passed Filter** -- At each signage point, a certain number of your plots will pass the plot filter. The numerator indicates the number of plots that are eligible to play in that specific Proof of Space lottery. For small farms, this number is often 0. The denominator indicates your farm's total number of plots. The numerator indicates the number of plots that are eligible to play in that specific Proof of Space lottery. For small farms, this number is often 0. The denominator indicates your farm's total number of plots. +- **Proofs Found** -- The number of valid proofs found at that signage point. If you are not in a pool, a number greater than 0 indicates that you have successfully found a proof and will likely win a block reward at the next transaction block. If you are in a pool, a number greater than 0 likely means that a valid partial proof was found and will be returned to your pool. If you are not in a pool, a number greater than 0 indicates that you have successfully found a proof and will likely win a block reward at the next transaction block. If you are in a pool, a number greater than 0 likely means that a valid partial proof was found and will be returned to your pool. ### Harvest panel @@ -66,13 +66,13 @@ Here is how to interpret each of the statistics in the above image: In the above image: - **Total farm size raw** -- The actual amount of space your farm is contributing to the network. -- **Total farm size effective** -- The amount of space your farm is effectively contributing, with uncompressed (C0) plots as the baseline. For example, if your farm consists entirely of C3 plots, according to the [plot compression table](/plotting-compression#compression-table), your farm's effective size should be 20% larger than its actual size. If you are using plots with a mixture of compression levels, the effective size of each of your plots will be taken into account in this number's calculation. +- **Total farm size effective** -- The amount of space your farm is effectively contributing, with uncompressed (C0) plots as the baseline. For example, if your farm consists entirely of C3 plots, according to the [plot compression table](/plotting-compression#compression-table), your farm's effective size should be 20% larger than its actual size. If you are using plots with a mixture of compression levels, the effective size of each of your plots will be taken into account in this number's calculation. For example, if your farm consists entirely of C3 plots, according to the [plot compression table](/plotting-compression#compression-table), your farm's effective size should be 20% larger than its actual size. If you are using plots with a mixture of compression levels, the effective size of each of your plots will be taken into account in this number's calculation. ## CLI Health ### Check if your farm thinks it's farming -Before going further, please make sure whether your farm actually considers itself to be farming. There's a good chance that you might not since you are still syncing blocks. +Before going further, please make sure whether your farm actually considers itself to be farming. There's a good chance that you might not since you are still syncing blocks. There's a good chance that you might not since you are still syncing blocks. 要检查您农场的状态，请像往常一样运行 `../activate` 命令（译注：仅通过源码方式安装才需要输入此命令），然后输入 `chia farm summary`。 如果输出的第一行看起来像这样： @@ -98,7 +98,7 @@ farmer: ### 检查是否有地块通过了初筛 -The most important metric to look out for is, whether your plots are passing the plot filter on your harvesting machines. 在通常的设置中，这涉及查看`~/.chia/mainnet/log`目录下的日志，在某些回合中，农场机器是否将地块标记为**可进行耕种**（eligible for farming）。 +The most important metric to look out for is, whether your plots are passing the plot filter on your harvesting machines. 在通常的设置中，这涉及查看`~/.chia/mainnet/log`目录下的日志，在某些回合中，农场机器是否将地块标记为**可进行耕种**（eligible for farming）。 在通常的设置中，这涉及查看`~/.chia/mainnet/log`目录下的日志，在某些回合中，农场机器是否将地块标记为**可进行耕种**（eligible for farming）。 `~/.chia/mainnet/log`目录可能看起来像这样： @@ -119,13 +119,13 @@ username@chia-farmer:~/.chia/mainnet/log$ tree 0 directories, 8 files ``` -Each log file contains log information about all the services ran by Chia. 如果运行的是一个全节点，这些日志可能会很复杂。 We're only interested whether or not plots pass the plot filter. 可以通过运行以下命令来检查： +Each log file contains log information about all the services ran by Chia. 如果运行的是一个全节点，这些日志可能会很复杂。 如果运行的是一个全节点，这些日志可能会很复杂。 We're only interested whether or not plots pass the plot filter. 可以通过运行以下命令来检查： 可以通过运行以下命令来检查： ```bash cat debug.log | grep "[0-9] plots were eligible for farming" ``` -The `cat` command is a \*nix program to get content of a file. With the pipe operator `|`we "pipe" the output to another program called `grep` which can filter textual input. 使用`grep`来过滤出现`"[0-9] plots were eligible for farming"`的内容，以查看是否已经有了符合条件的地块。 +The `cat` command is a \*nix program to get content of a file. With the pipe operator `|`we "pipe" the output to another program called `grep` which can filter textual input. 使用`grep`来过滤出现`"[0-9] plots were eligible for farming"`的内容，以查看是否已经有了符合条件的地块。 With the pipe operator `|`we "pipe" the output to another program called `grep` which can filter textual input. 使用`grep`来过滤出现`"[0-9] plots were eligible for farming"`的内容，以查看是否已经有了符合条件的地块。 示例输出可能如下所示： @@ -157,11 +157,11 @@ cat debug.log | grep "Found [1-9] proofs" 12:30:01.492 harvester src.harvester.harvester : INFO 1 plots were eligible for farming 23d3a7c90f... Found 1 proofs. Time: 0.57000 s. Total 100 plots Found 1 proofs. Time: 0.57000 s. Total 100 plots ``` -If you do this for all your log files and get a result, **great!** This means your farm is 100% working as expected. 可能还没有赢得一个区块，但已经接近成功了一次或多次！ +If you do this for all your log files and get a result, **great!** This means your farm is 100% working as expected. 可能还没有赢得一个区块，但已经接近成功了一次或多次！ 可能还没有赢得一个区块，但已经接近成功了一次或多次！ ### Can a Double NAT scenario impact my farm's ability to send valid proofs to the network? -是也不是。 Double NAT, while quirky, should work due to Chia's uPnP support. 然而，您可能无法通过这种方式将区块发送给其他节点。 "双重NAT"场景发生在客户端（收割机或节点）位于进行了两次NAT的网络内。 通常涉及客户端位于两个路由器后面，而不是一个，如下图所示： +是也不是。 Double NAT, while quirky, should work due to Chia's uPnP support. 然而，您可能无法通过这种方式将区块发送给其他节点。 然而，您可能无法通过这种方式将区块发送给其他节点。 "双重NAT"场景发生在客户端（收割机或节点）位于进行了两次NAT的网络内。 通常涉及客户端位于两个路由器后面，而不是一个，如下图所示： 互联网 --> 路由器 --> 路由器 --> 客户端 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-basics.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-basics.md index 5d013fe53f..bba5e90650 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-basics.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-basics.md @@ -3,9 +3,9 @@ title: Farming Basics slug: /farming-basics --- -耕种（Farming）是[生成地块](/plotting-basics)（plotting）后的下一步。 Once a plot has been created, you have a chance of winning Chia as long as the file is being stored and the Chia farming software is running. +耕种（Farming）是[生成地块](/plotting-basics)(/plotting-basics)（plotting）后的下一步。 Once a plot has been created, you have a chance of winning Chia as long as the file is being stored and the Chia farming software is running. -When farming, you allocate a certain amount of storage space in order to have a chance at winning Chia. The more plots you have, the higher your chances of winning. +When farming, you allocate a certain amount of storage space in order to have a chance at winning Chia. The more plots you have, the higher your chances of winning. The more plots you have, the higher your chances of winning. Farming is similar to a lottery. Each plot acts like a lottery ticket, where a new drawing is performed every 9 seconds or so. If you win the lottery, you earn the right to create a new block, and you will be rewarded with Chia. With an average of 4608 blocks a day, you'll have many chances to win. @@ -21,17 +21,17 @@ Prior wins (or lack thereof) do not determine new wins. 如果预计获得奖励 ## 使用联合耕种池来应对 -To combat the infrequency and inconsistency of winning, you can [join a pool](/pool-farming). It works similar to a lottery pool. Instead of occasionally earning a large reward, you will frequently earn a small payment. In the long run, pooling and solo-farming (aka **self-pooling**) will yield the same result (minus any pool fee), but pooling is much more predictable, and recommended for most farmers. +To combat the infrequency and inconsistency of winning, you can [join a pool](/pool-farming). It works similar to a lottery pool. Instead of occasionally earning a large reward, you will frequently earn a small payment. In the long run, pooling and solo-farming (aka **self-pooling**) will yield the same result (minus any pool fee), but pooling is much more predictable, and recommended for most farmers. It works similar to a lottery pool. Instead of occasionally earning a large reward, you will frequently earn a small payment. In the long run, pooling and solo-farming (aka **self-pooling**) will yield the same result (minus any pool fee), but pooling is much more predictable, and recommended for most farmers. -An additional benefit of pooling is instant feedback as to whether your farm is running properly. 如果是独自耕种，可能会不确定自己是否真的能赢得一个区块。 +An additional benefit of pooling is instant feedback as to whether your farm is running properly. 如果是独自耕种，可能会不确定自己是否真的能赢得一个区块。 如果是独自耕种，可能会不确定自己是否真的能赢得一个区块。 Chia设计了官方的联合耕种协议（pooling protocol），以一种其他加密货币从未尝试过的方式引入了矿池。 This allows for officially-supported predictability without compromising on decentralization. ## 区块奖励 -With each new block, a certain amount of Chia is rewarded to the farmer that created it. Chia launched with a block reward of 2 XCH per block. This comes out to 64 XCH distributed every 10 minutes. +With each new block, a certain amount of Chia is rewarded to the farmer that created it. With each new block, a certain amount of Chia is rewarded to the farmer that created it. Chia launched with a block reward of 2 XCH per block. This comes out to 64 XCH distributed every 10 minutes. This comes out to 64 XCH distributed every 10 minutes. -Every three years, there is a scheduled halving of the block reward. This means that three years after mainnet launch, the block reward is cut in half, to 1 XCH. +Every three years, there is a scheduled halving of the block reward. Every three years, there is a scheduled halving of the block reward. This means that three years after mainnet launch, the block reward is cut in half, to 1 XCH. 以下是完整的区块奖励计划： diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-compressed-plots.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-compressed-plots.md index 22ec12eccc..eadf555019 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-compressed-plots.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-compressed-plots.md @@ -7,13 +7,13 @@ slug: /farming-compressed-plots import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -As detailed in the [plotting](/plotting-basics) section, compressed plots are supported for both plotting and harvesting as of Chia version 2.0. Before you can harvest compressed plots, you need to inform your harvesters of the fact that they exist. +As detailed in the [plotting](/plotting-basics) section, compressed plots are supported for both plotting and harvesting as of Chia version 2.0. Before you can harvest compressed plots, you need to inform your harvesters of the fact that they exist. Before you can harvest compressed plots, you need to inform your harvesters of the fact that they exist. :::info -As of Chia version 2.0, decompression must be performed at the harvester level. You therefore will need to apply the settings listed on this page to each of your harvesters individually. This also means that each individual harvester will need to be capable of decompressing the plots that have been installed locally. +As of Chia version 2.0, decompression must be performed at the harvester level. You therefore will need to apply the settings listed on this page to each of your harvesters individually. As of Chia version 2.0, decompression must be performed at the harvester level. You therefore will need to apply the settings listed on this page to each of your harvesters individually. This also means that each individual harvester will need to be capable of decompressing the plots that have been installed locally. -In the future, we plan to enable decompression at the farmer level. This means that only one computer on your network will need to be equipped with a fast CPU or GPU for decompressing plots. +In the future, we plan to enable decompression at the farmer level. In the future, we plan to enable decompression at the farmer level. This means that only one computer on your network will need to be equipped with a fast CPU or GPU for decompressing plots. ::: @@ -22,44 +22,42 @@ In the future, we plan to enable decompression at the farmer level. This means t ### GUI 1. Navigate to the `Settings` panel in the lower-left corner of the GUI. -2. Click the `HARVESTER` tab at the top of the panel. The following screen will appear: +2. Click the `HARVESTER` tab at the top of the panel. The following screen will appear: The following screen will appear:
Enable compressed farming
3. Slide the `Enable compressed plot support` slider to the right, as shown in the above image. -4. For `Parallel Decompressor Count`, the default value of `1` will be fine for most users. Here are some details: +4. For `Parallel Decompressor Count`, the default value of `1` will be fine for most users. Here are some details: Here are some details: - This number _only_ affects the amount of memory used for decompression. - - The amount memory required will vary according to the level of compression. For example, if `Parallel Decompressor Count` is set to `1`, around 600-700 MB of memory will be consumed while decompressing a single C7 plot. + - The amount memory required will vary according to the level of compression. The amount memory required will vary according to the level of compression. For example, if `Parallel Decompressor Count` is set to `1`, around 600-700 MB of memory will be consumed while decompressing a single C7 plot. - The amount of memory required will scale linearly, so setting it to `2` will double the required memory. - If your harvester has sufficient memory, as well as a high CPU core count, you can increase this number. For example, `2` might be optimal for a 16-core CPU, or `4` for dual 32-core CPUs. + If your harvester has sufficient memory, as well as a high CPU core count, you can increase this number. For example, `2` might be optimal for a 16-core CPU, or `4` for dual 32-core CPUs. For example, `2` might be optimal for a 16-core CPU, or `4` for dual 32-core CPUs. - However, the generation and speed of your CPU will also have a large impact on the optimal setting. If you do increase `Parallel Decompressor Count`, be sure to monitor your harvester's performance as there is no one-size-fits-all solution. + However, the generation and speed of your CPU will also have a large impact on the optimal setting. However, the generation and speed of your CPU will also have a large impact on the optimal setting. If you do increase `Parallel Decompressor Count`, be sure to monitor your harvester's performance as there is no one-size-fits-all solution. -5. The default value for `Decompressor Thread Count` is `0`. This is the number of threads that will participate in decompressing plots. This number, multiplied by `Parallel Decompressor Count`, needs to less than or equal to the total number of harvester cores. +5. The default value for `Decompressor Thread Count` is `0`. This is the number of threads that will participate in decompressing plots. This number, multiplied by `Parallel Decompressor Count`, needs to less than or equal to the total number of harvester cores. This is the number of threads that will participate in decompressing plots. This number, multiplied by `Parallel Decompressor Count`, needs to less than or equal to the total number of harvester cores. -For example, if your harvester has one CPU with eight cores, you might use the following settings: -_ `Parallel Decompressor Count`: `1` -_ `Decompressor Thread Count`: `6` +For example, if your harvester has one CPU with eight cores, you might use the following settings: _ `Parallel Decompressor Count`: `1` _ `Decompressor Thread Count`: `6` This would instruct the harvester process to use six of the eight cores for decompressing plots, and to use the remaining cores to run the OS, etc. 5. If you want to use a GPU for harvesting, slide the `Enable GPU Harvesting` slider to the right, as shown in the above image. Note that in order to use this setting, your harvester must have an NVIDIA CUDA-class GPU. For harvesting C7 plots, 600-700 MB of DRAM is required. 6. If your harvester has multiple GPUs, you can use `GPU Device Index` to choose which one to use. If your harvester only has one GPU, then leave this set to `0`. -After all of these settings have been properly set, click the red `RESTART LOCAL HARVESTER TO APPLY CHANGES` button. After your harvester restarts, it will use the updated settings. +After all of these settings have been properly set, click the red `RESTART LOCAL HARVESTER TO APPLY CHANGES` button. After your harvester restarts, it will use the updated settings. After your harvester restarts, it will use the updated settings. ### CLI All of the new harvester settings live inside `~/.chia/mainnet/config/config.yaml`. -If you have never installed Chia on this harvester, `config.yaml` won't exist. In this case, run the following command to generate a new copy: +If you have never installed Chia on this harvester, `config.yaml` won't exist. In this case, run the following command to generate a new copy: In this case, run the following command to generate a new copy: ```bash chia init ``` -If you have previously installed Chia on this computer, then `config.yaml` likely already exists. In this case, you will need to add several new settings. However, +If you have previously installed Chia on this computer, then `config.yaml` likely already exists. In this case, you will need to add several new settings. However, In this case, you will need to add several new settings. However, - If you run `chia init` when the config file already exists, Chia won't make any modifications. - If you delete `config.yaml` and run `chia init`, the new settings will be added, but you will lose any custom changes you previously made. @@ -81,16 +79,16 @@ disable_cpu_affinity: false max_compression_level_allowed: 7 ``` -At this point, regardless of whether you are upgrading or running a new build of Chia on this harvester, your copy of `config.yaml` contains all of the latest settings. Their definitions and recommended values are as follows: +At this point, regardless of whether you are upgrading or running a new build of Chia on this harvester, your copy of `config.yaml` contains all of the latest settings. Their definitions and recommended values are as follows: Their definitions and recommended values are as follows: - `parallel_decompressor_count`: The number of CPUs to be used for decompressing plots. If this is set to `0`, then harvesting of compressed plots will be disabled. For GPU harvesting, set this value to `1`. For CPU harvesting, set it to the number of CPUs you want to use for decompression (typically `1`). -- `decompressor_thread_count`: The number of CPU threads that will participate in decompressing plots. This number multiplied by `Parallel Decompressor Count` needs to less than or equal to the total number of CPU cores. -- `use_gpu_harvesting`: Set to `true` to enable harvesting with a GPU. Note that in order to use this setting, your harvester must have an NVIDIA GPU with CUDA capability 5.2 and up, with at least 8GB of vRAM. -- `gpu_index`: If your harvester has multiple GPUs, use this setting to choose which one to use. If your harvester only has one GPU, then leave this set to `0`. +- `decompressor_thread_count`: The number of CPU threads that will participate in decompressing plots. `decompressor_thread_count`: The number of CPU threads that will participate in decompressing plots. This number multiplied by `Parallel Decompressor Count` needs to less than or equal to the total number of CPU cores. +- `use_gpu_harvesting`: Set to `true` to enable harvesting with a GPU. `use_gpu_harvesting`: Set to `true` to enable harvesting with a GPU. Note that in order to use this setting, your harvester must have an NVIDIA GPU with CUDA capability 5.2 and up, with at least 8GB of vRAM. +- `gpu_index`: If your harvester has multiple GPUs, use this setting to choose which one to use. If your harvester only has one GPU, then leave this set to `0`. If your harvester only has one GPU, then leave this set to `0`. - `enforce_gpu_index`: Set to `true` if your harvester has more than one GPU and you want to use one other than the default of `0`. -- `decompressor_timeout`: The number of seconds for your decompressor to time out. The default value of `20` is typically fine. -- `disable_cpu_affinity`: This should typically be `false`. When it is `false`, when using multiple CPU decompressors, each with multiple threads, the threads for each decompressor will be assigned to different physical CPUs. This prevents them for competing over compute time. If it is set to `true`, the threads for each decompressor will be assigned to the same CPU. -- `max_compression_level_allowed`: The highest level of compression your harvester will support. In Chia version 2.0, the maximum level is `7`. This will likely be increased in the future, but for now, you cannot increase it beyond the default. You can, however, set it to a lower number if desired. +- `decompressor_timeout`: The number of seconds for your decompressor to time out. The default value of `20` is typically fine. The default value of `20` is typically fine. +- `disable_cpu_affinity`: This should typically be `false`. `disable_cpu_affinity`: This should typically be `false`. When it is `false`, when using multiple CPU decompressors, each with multiple threads, the threads for each decompressor will be assigned to different physical CPUs. This prevents them for competing over compute time. If it is set to `true`, the threads for each decompressor will be assigned to the same CPU. This prevents them for competing over compute time. If it is set to `true`, the threads for each decompressor will be assigned to the same CPU. +- `max_compression_level_allowed`: The highest level of compression your harvester will support. In Chia version 2.0, the maximum level is `7`. This will likely be increased in the future, but for now, you cannot increase it beyond the default. You can, however, set it to a lower number if desired. In Chia version 2.0, the maximum level is `7`. This will likely be increased in the future, but for now, you cannot increase it beyond the default. You can, however, set it to a lower number if desired. After you have finished making these updates, save `config.yaml` and restart your harvester by running the following command: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-many-machines.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-many-machines.md index 980ed502b8..e51cb519dd 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-many-machines.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/farming-many-machines.md @@ -13,9 +13,9 @@ Always make sure to protect yourself from malicious actors by [securing your chi ::: -This guide will show you how to run a harvester on each machine in your network. This architecture is composed of one main machine which runs the farmer, full node, and wallet, and other machines which run only the harvester. 只有主机将连接到Chia网络。 +This guide will show you how to run a harvester on each machine in your network. This architecture is composed of one main machine which runs the farmer, full node, and wallet, and other machines which run only the harvester. 只有主机将连接到Chia网络。 This architecture is composed of one main machine which runs the farmer, full node, and wallet, and other machines which run only the harvester. 只有主机将连接到Chia网络。 -This is the recommended setup for all Chia farms that use more than one computer. It uses less bandwidth, space and CPU versus running a full node on each computer. It also keeps your keys safer because they will only need to be stored on one computer. Finally, it makes your overall farm quicker and more efficient when replying to challenges. +This is the recommended setup for all Chia farms that use more than one computer. It uses less bandwidth, space and CPU versus running a full node on each computer. It also keeps your keys safer because they will only need to be stored on one computer. Finally, it makes your overall farm quicker and more efficient when replying to challenges. It uses less bandwidth, space and CPU versus running a full node on each computer. It also keeps your keys safer because they will only need to be stored on one computer. Finally, it makes your overall farm quicker and more efficient when replying to challenges. 为了保障收割节点与主机之间的通信安全，使用TLS（Transport Layer Security）协议，其中**主机**将充当私有证书颁发机构(CA)，用于签署所有证书。 每个收割节点必须拥有自己的签名证书，以便与**主机**正确通信。 @@ -26,7 +26,7 @@ This is the recommended setup for all Chia farms that use more than one computer \_____ 收割机 3 (证书 C) ``` -If you are more of a visual learner, JM made a video outlining the steps from this tutorial. This video is from 2021, but the steps are still relevant today: +If you are more of a visual learner, JM made a video outlining the steps from this tutorial. This video is from 2021, but the steps are still relevant today: This video is from 2021, but the steps are still relevant today: @@ -52,7 +52,7 @@ If you are more of a visual learner, JM made a video outlining the steps from th 在生成地块后，请运行`chia plots check`命令确保一切正常运行。 -- A copy of your **main** machine CA directory needs to be accessible by your harvester machines. This directory is located in: +- A copy of your **main** machine CA directory needs to be accessible by your harvester machines. This directory is located in: This directory is located in: ```bash ~/.chia/mainnet/config/ssl/ca @@ -88,7 +88,7 @@ chia init -c :::warning -For step 4, you are using a copy of your `/ca` directory from your main machine temporarily. 请勿替换收割节点上的`/ca`文件夹。 将`/ca`目录放入收割节点上的临时文件夹中。 将暂时向收割节点展示这些文件，然后可以删除临时文件夹中的`/ca`目录。 This keeps your system more secure by limiting the exposure to your certificates. +For step 4, you are using a copy of your `/ca` directory from your main machine temporarily. 请勿替换收割节点上的`/ca`文件夹。 请勿替换收割节点上的`/ca`文件夹。 将`/ca`目录放入收割节点上的临时文件夹中。 将暂时向收割节点展示这些文件，然后可以删除临时文件夹中的`/ca`目录。 This keeps your system more secure by limiting the exposure to your certificates. ::: @@ -98,7 +98,7 @@ For step 4, you are using a copy of your `/ca` directory from your main machine ~/.chia/mainnet/config/config.yaml ``` -Search for the remote **`harvester`**'s farmer_peer section (NOT `full_node`). Enter the local IP address of your main machine (typically `192.168.xxx.yyy`) as the `host` value. +Search for the remote **`harvester`**'s farmer_peer section (NOT `full_node`). Enter the local IP address of your main machine (typically `192.168.xxx.yyy`) as the `host` value. Enter the local IP address of your main machine (typically `192.168.xxx.yyy`) as the `host` value. In other words, replace `` in the following snippet with your main machine's local IP: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/pool-farming.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/pool-farming.md index a51b1a451e..b3697c8046 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/pool-farming.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/farming/pool-farming.md @@ -15,13 +15,13 @@ Chia的联合耕种协议（pooling protocol）允许将地块分配给“联合 :::note -The official pooling protocol was introduced in verion 1.2 in mid-2021. All plots created before this point, as well as newer plots created with following the pooling protocol, are not eligible for pooling. If you have any of these "OG" plots, you can either recreate them using a plot NFT, or co-farm them on the same machine as your official pool plots. +The official pooling protocol was introduced in version 1.2 in mid-2021. All plots created before this point, as well as newer plots created with following the pooling protocol, are not eligible for pooling. The official pooling protocol was introduced in version 1.2 in mid-2021. All plots created before this point, as well as newer plots created with following the pooling protocol, are not eligible for pooling. If you have any of these "OG" plots, you can either recreate them using a plot NFT, or co-farm them on the same machine as your official pool plots. ::: ### 第一步：同步全节点和钱包 -In order to set up your farm for pooling, you need to have a synced full node and wallet. In the upper-right corner of your wallet, you should see green icons next to `FUll NODE` and `WALLET`: +In order to set up your farm for pooling, you need to have a synced full node and wallet. In the upper-right corner of your wallet, you should see green icons next to `FUll NODE` and `WALLET`: In the upper-right corner of your wallet, you should see green icons next to `FUll NODE` and `WALLET`:
Sync status @@ -37,7 +37,7 @@ For more info, see our [blog post](https://www.chia.net/2023/03/19/introducing-c ### 第二步：获取一些XCH -开始联合耕种之前，请确保钱包里面拥有一小笔XCH。 可以向朋友索取mojo（1 mojo等于0.000000000001 XCH），或者到https://faucet.chia.net/获取mojo。 You can use the receive address on the `Tokens` page, and you can also create new receive addresses. Any of the receive addresses can be used; they are all part of the same wallet. +开始联合耕种之前，请确保钱包里面拥有一小笔XCH。 可以向朋友索取mojo（1 mojo等于0.000000000001 XCH），或者到https://faucet.chia.net/获取mojo。 You can use the receive address on the `Tokens` page, and you can also create new receive addresses. Any of the receive addresses can be used; they are all part of the same wallet. Any of the receive addresses can be used; they are all part of the same wallet. ### 第三步：创建联合耕种农田（Plot NFT） @@ -71,9 +71,9 @@ Click the `Pooling` icon on the left side of your wallet, and click `JOIN A POOL
-Select `Connect to pool`. You will need to enter a valid pool URL. For a list of Chia pools, see [chialinks.com](https://chialinks.com/pools). +Select `Connect to pool`. You will need to enter a valid pool URL. Select `Connect to pool`. You will need to enter a valid pool URL. For a list of Chia pools, see [chialinks.com](https://chialinks.com/pools). -Creating a plot NFT requires an on-chain transaction that will cost one mojo. You are also recommended to enter a blockchain fee. Depending on how busy the network is, a one-mojo fee is typically enough to complete your transaction within a few minutes. +Creating a plot NFT requires an on-chain transaction that will cost one mojo. You are also recommended to enter a blockchain fee. Depending on how busy the network is, a one-mojo fee is typically enough to complete your transaction within a few minutes. You are also recommended to enter a blockchain fee. Depending on how busy the network is, a one-mojo fee is typically enough to complete your transaction within a few minutes.
Create a plot NFT @@ -81,7 +81,7 @@ Creating a plot NFT requires an on-chain transaction that will cost one mojo. Yo
-If you entered a valid pool URL, the details will pop up. If everything looks acceptable, click `CREATE`: +If you entered a valid pool URL, the details will pop up. For example, this pool has a fee of 1%. If everything looks acceptable, click `CREATE`: If everything looks acceptable, click `CREATE`:
Pool details @@ -89,7 +89,7 @@ If you entered a valid pool URL, the details will pop up. If everything looks ac
-Your transaction will be pushed to the blockchain. While it is pending, a new screen will appear: +Your transaction will be pushed to the blockchain. While it is pending, a new screen will appear: While it is pending, a new screen will appear:
Plot NFT pending @@ -112,11 +112,11 @@ You can now start creating plots for this Plot NFT, which means these plots will Detailed instructions can be found in the "How to Plot" page: - Plotting from the [CLI](/plotting-how-to#cli-plotting) -- Plotting from the [GUI](/plotting-how-to#gui-plotting) +- Plotting from the [GUI](/plotting-how-to#图形用户界面gui生成地块) ### 第五步：管理联合耕种农田。 -You should see your plots in the `Pooling` dialog. The status should say `Pooling``. 在这里，可以看到当前农田的难度，已获得的积分（points）以及联合耕种池认为您拥有的积分（积分余额）。 +You should see your plots in the `Pooling` dialog. The status should say `Pooling``. 在这里，可以看到当前农田的难度，已获得的积分（points）以及联合耕种池认为您拥有的积分（积分余额）。 The status should say `Pooling`. 在这里，可以看到当前农田的难度，已获得的积分（points）以及联合耕种池认为您拥有的积分（积分余额）。
Plot NFT details @@ -128,7 +128,7 @@ You should see your plots in the `Pooling` dialog. The status should say `Poolin 积分是一种计算地块找到了多少证明的方式。 每个K32地块每天平均会获得10个积分，与难度无关。 积分与Chia（XCH）不同。 积分只是反映了进行了多少耕种的值。 可以将其视为一种会计工具。 根据您获得的积分数，由联合耕种池定期发放XCH，并将您的积分重置为0，这是矿池的责任。 -To change pools, click on the `CHANGE POOL` button and enter the new pool URL. 请注意，更改联合耕种池有一个等待期，可能会持续几分钟到一小时左右。 请在此过程中不要关闭应用程序。 可以随意更改联合耕种池，而且不需要进行注册或支付任何罚款。 请注意，如果更改了联合耕种池，之前的耕种池不再有义务继续向你支付收益。 +To change pools, click on the `CHANGE POOL` button and enter the new pool URL. 请注意，更改联合耕种池有一个等待期，可能会持续几分钟到一小时左右。 请注意，更改联合耕种池有一个等待期，可能会持续几分钟到一小时左右。 请在此过程中不要关闭应用程序。 可以随意更改联合耕种池，而且不需要进行注册或支付任何罚款。 请注意，如果更改了联合耕种池，之前的耕种池不再有义务继续向你支付收益。 您应该确保在过去24小时内的积分数是准确的。 每天每个k32地块应该获得大约10个积分，所以如果有100个k32的地块，每天应该获得大约1000个积分。 确保您的积分在持续增长。 支付后，积分余额将重置为零。 积分将随机出现，因为查找证明也是随机的。 因此，预计会有很多变化，并且会有好运和坏运的时候。 @@ -144,7 +144,7 @@ To change pools, click on the `CHANGE POOL` button and enter the new pool URL. ### 多台电脑 -You can take your 24-word seed phrase and enter it into a different computer, and when it is synched, the current Plot NFTs and pool information will be automatically downloaded from the blockchain. All information about your pool, plot NFTs, and smart contract addresses is completely backed up on the blockchain, and can be recovered using the seed phrase. +You can take your 24-word seed phrase and enter it into a different computer, and when it is synched, the current Plot NFTs and pool information will be automatically downloaded from the blockchain. All information about your pool, plot NFTs, and smart contract addresses is completely backed up on the blockchain, and can be recovered using the seed phrase. All information about your pool, plot NFTs, and smart contract addresses is completely backed up on the blockchain, and can be recovered using the seed phrase. ### 多个密钥 @@ -156,7 +156,7 @@ You can take your 24-word seed phrase and enter it into a different computer, an ### 区块链手续费 -Blockchain fees are paid to the creator of the block (farmers), to incentivize them to include your transaction. If the blockchain is busy, you might have to pay small a small fee to get your transaction included. (Creating a plot NFT and changing pools both require an on-chain transaction.) +Blockchain fees are paid to the creator of the block (farmers), to incentivize them to include your transaction. If the blockchain is busy, you might have to pay small a small fee to get your transaction included. (Creating a plot NFT and changing pools both require an on-chain transaction.) If the blockchain is busy, you might have to pay small a small fee to get your transaction included. (Creating a plot NFT and changing pools both require an on-chain transaction.) ### 无效状态 @@ -238,11 +238,11 @@ chia plotnft show ### 什么是联合耕种农田？ -一个联合耕种农田（plot NFT）是区块链上的智能币或代币，允许用户管理他们在耕种池中的成员资格。 Users can assign the plot NFT to any pool they want, at any point. 在生成地块时，可以选择一个农田，并且该地块将永远与该农田绑定在一起。 农田是“非同质化”的，因为它们不可互换；每个农田代表一个独特的耕种池合约。 +一个联合耕种农田（plot NFT）是区块链上的智能币或代币，允许用户管理他们在耕种池中的成员资格。 Users can assign the plot NFT to any pool they want, at any point. 在生成地块时，可以选择一个农田，并且该地块将永远与该农田绑定在一起。 在生成地块时，可以选择一个农田，并且该地块将永远与该农田绑定在一起。 农田是“非同质化”的，因为它们不可互换；每个农田代表一个独特的耕种池合约。 ### 需要支付XCH来创建联合耕种农田或切换耕种池吗？ -Each plot NFT you create will require 1 mojo (1 trillionth of a XCH) + transaction fee. 切换耕种池只需要支付交易手续费。 如果您没有任何XCH，可以从Chia的官方水龙头获得100个mojo：https://faucet.chia.net/ +Each plot NFT you create will require 1 mojo (1 trillionth of a XCH) + transaction fee. 切换耕种池只需要支付交易手续费。 切换耕种池只需要支付交易手续费。 如果您没有任何XCH，可以从Chia的官方水龙头获得100个mojo：https://faucet.chia.net/ ### 可以同时在旧土地和新地块上耕种吗？ @@ -260,7 +260,7 @@ Each plot NFT you create will require 1 mojo (1 trillionth of a XCH) + transacti Chia has three major differences from most other crypto pooling protocol: -1. Joining pools is permissionless. 在加入之前不需要在耕种池(矿池)服务器上注册账户。 +1. Joining pools is permissionless. 在加入之前不需要在耕种池(矿池)服务器上注册账户。 在加入之前不需要在耕种池(矿池)服务器上注册账户。 2. Farmers receive 1/8 of the block reward plus transaction fees, while the pool receives 7/8 of the reward to redistribute (minus pool fees) amongst all pool participants. 3. The farmer with the winning proof will farm the block, not the pool server. @@ -321,8 +321,8 @@ Python ### How does one calculate a farmer's space? -A farmer's space can be estimated by the number of points submitted over each unit of time, or points/second. 每个k32地块平均每天获得10个积分（points）。 所以每个地块的算力为 `10 / 86400 = 0.0001157 points/second`。 Per byte, that is `L = 0.0001157 / 108884400275 = 1.06259482265 * 10^-15`. To calculate total space `S`, take the total number of points found `P`, and the time period in seconds `T` and do `S = P / (L*T)`. -For example for 340 points in 6 hours, use `P=340, T=21600, L=1.06259482265e-15`, `S = 340/(21600*1.06259482265e-15) = 14,813,492,786,900 bytes`. Dividing by `1024^4` we get `13.4727932044 TiB`. +A farmer's space can be estimated by the number of points submitted over each unit of time, or points/second. 每个k32地块平均每天获得10个积分（points）。 每个k32地块平均每天获得10个积分（points）。 所以每个地块的算力为 `10 / 86400 = 0.0001157 points/second`。 Per byte, that is `L = 0.0001157 / 108884400275 = 1.06259482265 * 10^-15`. Per byte, that is `L = 0.0001157 / 108884400275 = 1.06259482265 * 10^-15`. To calculate total space `S`, take the total number of points found `P`, and the time period in seconds `T` and do `S = P / (L*T)`. +For example for 340 points in 6 hours, use `P=340, T=21600, L=1.06259482265e-15`, `S = 340/(21600*1.06259482265e-15) = 14,813,492,786,900 bytes`. Dividing by `1024^4` we get `13.4727932044 TiB`. Dividing by `1024^4` we get `13.4727932044 TiB`. :::info diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/bridge-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/bridge-guide.md new file mode 100644 index 0000000000..bd82089fee --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/bridge-guide.md @@ -0,0 +1,333 @@ +--- +title: XCH Bridge Guide +slug: /bridge-guide +--- + +## Intro + +A _cryptocurrency bridge_ is a powerful tool that enables seamless transfers of digital assets between different blockchain networks, breaking down the barriers of blockchain interoperability. The first Chia blockchain bridge by Warp.Green is now available, paving the way for anyone to access XCH. + +As the first of many bridges to come, Warp.Green marks an exciting milestone in our journey toward greater access to chia (XCH). To help you get started, here's a introductory guide on how to use the Warp.Green bridge. + +## The Warp.green Bridge + +The [Warp.green bridge](https://www.warp.green/) is a messaging protocol that enables bridging assets between Chia and other blockchains. It is an open-source project located on [GitHub](https://github.com/warpdotgreen). It was developed by Warp.green, which is not affiliated with Chia Network Inc. + +This guide will show you how to send ETH from the [Base](https://www.base.org/) blockchain (an Ethereum L2) to the Chia blockchain. The transfer will take a total of 15-20 minutes, though the initial setup could take considerably longer if you are not familiar with the technologies involved. + +:::info + +It is also possible to bridge assets from Ethereum to Chia, but we chose the Base chain for this guide because it tends to have lower fees. + +In addition, it is possible to bridge assets in the other direction: from Chia to Ethereum/Base. This guide doesn't demonstrate this functionality, but the basic technique is quite similar. + +Finally, note that the bridge is set up to allow for bridging _any_ Chia or Ethereum asset. However, only a limited number of assets are currently supported. A list of supported assets is maintained at [warp.green/bridge/assets](https://www.warp.green/bridge/assets). + +::: + +## Set up MetaMask + +[MetaMask](https://metamask.io/) is one of the most popular wallets for storing digital assets such as ETH, and it supports the Base blockchain. We will use MetaMask for this guide, so if you want to follow along, you will need to install it as a web browser extension. But don't worry – if you want to use a different Base wallet, the instructions will likely be similar. + +After you have installed MetaMask, click the browser extension button ("1" in the following image), then click the dropdown to change blockchains ("2"): + +

+ bridge +

+
+ +By default, Ethereum's mainnet will be selected. The Warp.green bridge _will_ work with this network, but for this guide, we will use Base instead. Click `+ Add network`: + +

+ bridge +

+
+ +Several supported networks will be displayed. Locate `Base Mainnet` and click `Add`: + +

+ bridge +

+
+ +Verify that you are adding the correct network. The Chain ID for the Base mainnet is `8453`. Make sure this number is shown, and click `Approve`: + +

+ bridge +

+
+ +The network should be added successfully. Click `Switch to Base Mainnet`: + +

+ bridge +

+
+ +You will be given some important info about this network. Read this info carefully, then click `Got it`: + +

+ bridge +

+
+ +In order to use this wallet for the bridge, you will need to add funds. In this example, the MetaMask wallet was funded with 0.0057 ETH on the Base blockchain: + +

+ bridge +

+
+ +After your Ethereum wallet has been funded, you can set up a Chia wallet. + +## Set up a Chia wallet + +While several Chia wallets exist, currently the bridge only supports wallets that use WalletConnect, as well as [Goby](https://www.goby.app/). For this example, we will use the Chia reference wallet. See our [wallet guide](/getting-started/wallet-guide/#use-the-chia-wallet) for instructions on setting up this wallet. + +You will need to add some XCH to the reference wallet in order to pay fees. In the image below, the wallet contains 0.001 XCH. Typically, this amount will be sufficient. + +We're going to send a wrapped form of ETH to the Chia reference wallet. If you are using Chia 2.3.1 or later, your wallet will automatically recognize the wrapped ETH, but it's still a good idea to add this asset manually. + +:::info + +Regardless of which blockchain you are using, when you receive a bridged token, it will be a "wrapped" version of the native token. The Warp.green bridge calls its tokens "warped" instead of "wrapped". There is no material difference between these two terms; they can be used interchangeably. + +::: + +Click `MANAGE TOKEN LIST`: + +

+ bridge +

+
+ +Locate `Base Warped milliETH` and click the slider to enable this asset. Feel free to double-check that the asset's ID matches the one from the [asset list](https://www.warp.green/bridge/assets) on Warp.green's website: + +

+ bridge +

+
+ +Your wallet will add `Base Warped milliETH`: + +

+ bridge +

+
+ +:::info + +One `Base Warped milliETH` is the equivalent to 1/1000 of one ETH. This denomination was chosen due to the differences in decimals on Chia and Ethereum. + +::: + +## Connect your wallets to the bridge + +Using the same browser where you installed MetaMask, browse to [warp.green/bridge](https://www.warp.green/bridge). In order to use the bridge, you will need to connect both of your wallets. + +### Connect your ETH wallet + +Click `Connect ETH Wallet`: + +

+ bridge +

+
+ +Click `MetaMask` (or whichever wallet you used on the Ethereum side): + +

+ bridge +

+
+ +Select the account(s) you want to connect to the bridge. If you just installed MetaMask, there will only be one account. Click `Next`: + +

+ bridge +

+
+ +Click `Connect` to connect your MetaMask wallet to the bridge: + +

+ bridge +

+
+ +Your MetaMask wallet is now connected to the bridge. + +### Connect your Chia wallet + +Click `Connect Wallet`: + +

+ bridge +

+
+ +Click `Wallet Connect` if you are using the Chia reference wallet: + +

+ bridge +

+
+ +You will be shown a QR code (not shown here). In this example, we'll click the `Copy Link` button. + +Next, open your reference wallet, click the WalletConnect icon ("1" in the image below), then click `ADD CONNECTION` ("2"): + +

+ bridge +

+
+ +Paste the link you previously copied, and click `CONTINUE`: + +

+ bridge +

+
+ +Your Chia reference wallet will now be connected to the bridge. Click `CLOSE`: + +

+ bridge +

+
+ +The bridge will request an address from your wallet. It may perform other requests as well. Click `CONFIRM` for each request: + +

+ bridge +

+
+ +Return to your web browser. You should see `Connected` displayed under `Wallet Connect`. If so, you can close this dialog: + +

+ bridge +

+
+ +## Initiate the transfer + +The bridge will ask you to enter an amount to transfer. By default, the asset to transfer will be USDC. However, in this example, we will transfer ETH: + +

+ bridge +

+
+ +Enter the amount to transfer. Also, verify that the `From` and `To` chains are accurate. For this example, we will transfer 0.001 ETH from Base to Chia. + +:::info + +The Base blockchain will charge a fee, so you will not be able to send the full amount in your MetaMask wallet. In this example, 0.00000465 ETH was the required fee. This fee will vary, depending on which blockchain you are using, and how busy the network is. + +::: + +After you have verified this info, click `Bridge`: + +

+ bridge +

+
+ +In Step 1 of the transfer, you will be given one more chance to verify the accuracy of everything you have entered. + +:::warning caution + +Be sure to read this dialog carefully, and verify that all information contained within is accurate. + +::: + +:::note note on fees + +Several fees may apply when using the bridge: + +Each blockchain charges a fee to use its network. The size of each fee depends on how busy the network is, as well as how long you are willing to wait for your transaction to be confirmed. Generally speaking, the fees on Base are significantly lower than those on Ethereum. On Chia, the network is often not busy enough to require any fees. + +In addition, a "toll" is automatically deducted for using the bridge. The toll is a small charge (either 0.001 XCH or 0.00001 ETH, depending on the chain where the transaction originated), collected solely to prevent network spam. This money does not go to the bridge or to its operators. Instead, it is redirected to the farmer/miner of the block which includes your transaction. + +Finally, the bridge itself charges a 0.3% tip for using the protocol. This tip is split among the bridge validators and helps to cover the costs associated with maintaining the bridge. + +For more information, see [warp.green's documentation](https://docs.warp.green/). + +::: + +If everything looks good, click `Initiate Bridging`: + +

+ bridge +

+
+ +MetaMask will pop up, and you will be shown the details of your transfer. This includes the current blockchain fee amount. Click `Confirm` to accept the fee and initiate the transfer: + +

+ bridge +

+
+ +You will now be taken to Step 2 of the transfer. Before completing the transfer, you will need to wait around 10-15 minutes; the exact time can vary a bit. The reason for this delay is to avoid funds being lost in blockchain reorgs: + +

+ bridge +

+
+ +Leave this browser window open, and return to it after 15 minutes. + +### Complete the transfer + +After waiting for around 15 minutes, the transfer will reach Step 3. Click `Generate Offer via Wallet`: + +

+ bridge +

+
+ +Change to your Chia reference wallet. You may see a dialog asking for permission to execute `getWallets`. If so, Click `CONFIRM`: + +

+ bridge +

+
+ +You may need to grant permission to execute one or more additional methods. Click `CONFIRM` on these dialogs. Eventually, you will see a dialog with a `SHOW OFFER DETAILS` button. Click this button: + +

+ bridge +

+
+ +You will be shown the details of the transfer from the bridge to your wallet. By default, no blockchain fee will be used. However, if you have available funds (the small circle in the image below), we recommend that you add a fee in order to expedite the transfer. Either way, leave the `In exchange for` side of the dialog blank. Click `CLOSE` when you are finished reviewing this dialog: + +

+ bridge +

+
+ +If you added a blockchain fee, it will now appear in the `Confirmation Request` dialog. Click `CONFIRM`: + +

+ bridge +

+
+ +Return to your web browser. The transfer will now be in progress. This should be completed in 1-5 minutes, depending on how busy the Chia network is, along with the size of your fee: + +

+ bridge +

+
+ +After the transfer has completed, return to the reference wallet. It should now contain the `Base Warped milliETH`. In this example, the bridge charged a 0.3% fee, so 0.997 wmilliETH.b was transferred. Recall that this amount is worth 0.000997 ETH: + +

+ bridge +

+
+ +Congratulations! You have successfully transferred ETH from the Base chain to Chia. If you would like to exchange the wmilliETH.b for another asset, you could head to a decentralized exchange such as [dexie.space](https://dexie.space/), or an AMM such as [tibetswap.io](https://v2.tibetswap.io/). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/farming-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/farming-guide.md index d37da76cab..043ac74a80 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/farming-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/farming-guide.md @@ -310,7 +310,7 @@ Pools typically require you to wait for 30 minutes before leaving. This is to pr :::info -Chia's pooling protocol has several significant advantages over pools on other blockchains. Read more about these advantages, as well as the technical details of how the protocol works, in our [pooling section](/introduction#pooling). +Chia's pooling protocol has several significant advantages over pools on other blockchains. Read more about these advantages, as well as the technical details of how the protocol works, in our [pooling section](/introduction#矿池pooling). ::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/installation.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/installation.md index e31ecc85d3..70e3d5fed9 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/installation.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/installation.md @@ -180,6 +180,9 @@ chia stop -d all # Deactivate the virtual environment deactivate +# Remove the current virtual environment +rm -r venv + # Pull the latest version git fetch git checkout latest @@ -240,6 +243,9 @@ chia stop -d all # Deactivate the virtual environment deactivate +# Remove the current virtual environment +rm -r venv + # Pull the latest version git fetch git checkout latest @@ -441,13 +447,13 @@ pip install --extra-index-url https://pypi.chia.net/simple chia-blockchain miniu _**These instructions were tested with Chia 1.1.4 on FreeBSD 11.3- and 11.4-RELEASE, newer versions may exist**_ -\*\*\*==crwdHRulesLBB_2_BBsuleRHdwrc== +--- #### Upgrading Existing Chia Installs If you're upgrading from a previously built chia installation, exit from your previous venv environment (`deactivate`), create a new directory in which to place the latest Chia (e.g. `mkdir ~/chia-1.0.5 && cd ~/chia-1.0.5`), clone the latest repo (`git clone https://github.com/Chia-Network/chia-blockchain.git -b latest`), enter it and create a new Python virtual environment within it (`python3 -m venv venv`). Now, activate the newest environment (`. venv/bin/activate`), upgrade pip (`pip install --upgrade pip`). Now you may skip down to the [clvm_rs install section](#clvm_rs) and begin there. -\*\*\*==crwdHRulesLBB_2_BBsuleRHdwrc== +--- #### Why This Manual Installation? @@ -692,7 +698,7 @@ sed -i .bak 's/enable_upnp: True/enable_upnp: False' ~/.chia/mainnet/config/conf While you don't absolutely need port 8444 forwarded to your Chia node, it is advised that you do so that other peers may connect to you instead of you solely connecting to them. For the average at-home farmer it is advised you do not disable UPnP unless you absolutely know what you're doing or have another node on your local network already using the port and are planning to [Farm on Many Machines](https://docs.chia.net/farming-on-many-machines/). -\*\*\*==crwdHRulesLBB_2_BBsuleRHdwrc== +--- #### Installed and Ready to Farm! @@ -1042,7 +1048,7 @@ If all else fails, rebooting the machine and restarting the chia daemon/processe To join a testnet, follow the instructions on [How to Join the Official Testnet](/testnets#join-the-official-testnet). -It is recommended that you keep a separate testnet environment by prepending `CHIA_ROOT="~/.chia/testnetx"` to all of your cli commands. For example, `CHIA_ROOT="~/.chia/testnet10" chia init`. An easier way to do this is to run `export CHIA_ROOT="~/.chia/testnet10"` so that all commands will use testnet10 instead of mainnet. If you're using a version above 1.2.11, you can update all config values to the testnet values by running `chia configure -t true`. +It is recommended that you keep a separate testnet environment by prepending `CHIA_ROOT="~/.chia/testnetx"` to all of your cli commands. For example, `CHIA_ROOT="~/.chia/testnet11" chia init`. An easier way to do this is to run `export CHIA_ROOT="~/.chia/testnet11"` so that all commands will use testnet11 instead of mainnet. You can update all config values to the testnet values by running `chia configure -t true`. ## Beta and release candidate installations @@ -1112,7 +1118,16 @@ chia init -### Apt +### From packaged installer + + + ```bash # Install packages @@ -1131,3 +1146,20 @@ sudo apt-get install chia-blockchain # Use chia-blockchain-cli instead for CLI only ``` + + + + +```bash +# Navigate to downloads page +Open https://github.com/Chia-Network/chia-blockchain/releases in a web browser + +# Download the correct asset +Navigate to the release candidate of interest and download the necessary installer for your OS (ex. exe for windows) + +# Install the downloaded installer +Using your system finder/file explorer install the downloaded installer (note - make sure no other versions of chia are installed prior to this step) +``` + + + diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/introduction.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/introduction.md index 67623933b5..c8dfa420df 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/introduction.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/introduction.md @@ -12,7 +12,7 @@ Chia是一种具有智能交易能力的加密货币和区块链。 它从头开 Chia的主网于2021年3月19日推出。 其生态系统的开发正在进行中，已发布了[CAT](https://chialisp.com/cats)、[NFT](https://chialisp.com/nfts)、[报价（offer）](https://chialisp.com/offers) 和 [DID](https://chialisp.com/dids) 等基础设施。 -This page will give a brief overview of Chia and its various components. If you are interested in becoming a Chia farmer, feel free to skip ahead to the [Beginner's Guide to Farming](/farming-guide). +This page will give a brief overview of Chia and its various components. This page will give a brief overview of Chia and its various components. If you are interested in becoming a Chia farmer, feel free to skip ahead to the [Beginner's Guide to Farming](/farming-guide). ## 时空证明（Proof of Space and Time） @@ -30,7 +30,7 @@ Chia使用硬币模型来跟踪网络的状态。 在这个模型中，硬币（ 有关更多信息，请查看[硬币模型简介页面](/coin-set-intro)和[Chialisp.com](https://chialisp.com) 网站。 ::: -## Pooling +## 矿池（Pooling） 与许多其他区块链一样，Chia允许连接矿池来确保小规模的农民能够平滑的获得奖励。 然而，Chia的矿池协议具有三个独特的特点。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/testnets.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/testnets.md index 44cb130fc7..d36b4b1a6c 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/testnets.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/testnets.md @@ -5,8 +5,11 @@ slug: /testnets :::note -Testnet 10 is the supported testnet. Testnet 7 may remain active, but is no longer officially supported by Chia Network Inc. +Testnet 10 is the supported testnet. + +Testnet 7 may remain active, but is no longer officially supported by Chia Network Inc. Testnets can be used to test the chia software with coins that have no real world value.\ +If you want to run the Chia blockchain mainnet, use the [mainnet installation](/installation) instructions.\ If you want to run the Chia blockchain mainnet, use the [mainnet installation](/installation) instructions. ::: @@ -40,8 +43,12 @@ This step is optional, but it will speed up syncing with the testnet - Linux users: `wget https://databases.chia.net/file/chia-public-databases/blockchain_v2_testnet10.sqlite.gz` while in the directory (a v1 DB is also available, but no longer updated). - Windows users: download it from [https://downloads.chia.net/testnet10/](https://downloads.chia.net/testnet10/) and move it to the db folder in the mainnet/ directory in the Chia root folder (i.e. \~/.chia/mainnet/db is the database directory). +:::note + _Make sure to unzip the database before continuing to the next step._ +::: + :::tip Prior to starting your node, it is recommended to delete `peers.dat`, located in `~/.chia/mainnet/db`. If you don't delete this file you might see `WARNING Invalid handshake with peer` in your log file. The reason for this is that peers.dat will contain mainnet peers, which are not running on the testnet. If you do see these warnings, there's no requirement to take further action -- they'll eventually stop appearing as your invalid peers are replaced with valid ones. @@ -86,7 +93,7 @@ _These instructions are tailored for Linux. A similar approach could likely be f 在某些情况下，您可能希望在主网上耕种的同时，在其中一个测试网络上也进行耕种，而不会将它们从主网中移除。 This is doable with a bit of extra legwork to set up unique ports for the testnet chia installation. -有几个设置的选项。 You can either ensure you have the CHIA_ROOT set to unique values for each instance you want to run, or else run the installations on separate users. These instructions will show setting a specific CHIA_ROOT. +有几个设置的选项。 有几个设置的选项。 You can either ensure you have the CHIA_ROOT set to unique values for each instance you want to run, or else run the installations on separate users. These instructions will show setting a specific CHIA_ROOT. ### Set Up mainnet installation @@ -97,6 +104,7 @@ For the mainnet installation, we will stick with the default ports and CHIA_ROOT :::note (Optional) Install `yq` to make editing the yaml files easier [https://github.com/mikefarah/yq#install](https://github.com/mikefarah/yq#install).\ +Alternatively, you can manually edit the ports in `config.yaml`.\ Alternatively, you can manually edit the ports in `config.yaml`. ::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/timelords.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/timelords.md new file mode 100644 index 0000000000..286e8f95af --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/timelords.md @@ -0,0 +1,321 @@ +--- +title: Timelords +slug: /timelord-install +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::warning +**DO NOT** overclock ASICs, overclocking diminishes the life of the ASIC! +::: + +Timelord architecture information can be found [here](/timelord-architecture). +The hw_vdf_client parameter information can be found [here](/asic-cli). + +--- + +## Timelord Requirements and Dependencies + +:::info +Due to restrictions on how [MSVC](https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B) handles 128 bit numbers and how Python relies upon MSVC, it is not possible to build and run Timelords of all types on Windows. +Running a timelord on a farming machine will reduce the efficiency of the farmer and the timelord, for this reason it is recommended to have a dedicated machine for running timelords. +::: + +Requirements: + +1. Software Timelord + - With the release of ASIC timelords, software timelords will have a near impossible time competing. It is recommended to only run a software timelord for experimentation and learning purposes. + - Dedicated host machine that is a modern gaming PC with minimum 6 fast cores and 8GB of RAM. +2. Bluebox Timelord + - Dedicated host machine that is a modern gaming PC with minimum 6 fast cores and 8GB of RAM. +3. ASIC Timelord + - The ASIC hardware + - Dedicated host machine that is a modern gaming PC with minimum 6 fast cores and 8GB of RAM. + - Two USB-C cables (one for power and one for data). Preferably USB-C to USB-C but we have successfully tested USB-A to USB-C without too much performance loss. + +Dependencies: + +- linux OS, our testing has been with Ubuntu 22 and newer +- git (if installing from source) +- ca-certificates curl gnupg (if installing from APT or if running an ASIC - RECOMMENDED) + +--- + +## Installing a Timelord + +:::info +Timelords execute sequential verifiable delay functions (proofs of time or VDFs), that get added to blocks to make them valid. This requires fast CPUs and a few cores per VDF. +::: + + + +:::info +Use `chia-blockchain-cli` instead of `chia-blockchain` for CLI only version that does not have a GUI. +::: + +```bash +# Install packages +sudo apt-get update +sudo apt-get install ca-certificates curl gnupg + +# Add GPG key +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg + +# Set up repository +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chia.list > /dev/null +sudo apt-get update + +# Install chia-blockchain +sudo apt-get install chia-blockchain + +# Launch timelord +chia start node timelord & +``` + + + + +```bash +# Install packages +sudo apt-get update +sudo apt-get install ca-certificates curl gnupg + +# Add GPG key +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg + +# Set up repository +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chia.list > /dev/null +sudo apt-get update + +# Install chia-blockchain +sudo apt-get install chia-blockchain + +# Bluebox timelord setup +For bluebox timelords you will need to make two changes to `~/.chia/mainnet/config.yaml`. +- In the `timelord:` section, set `bluebox_mode:` to `True`. +- In the `full_node:` section and set `send_uncompact_interval:` to something greater than 0. We recommend `300` seconds there so that your Bluebox has some time to prove through a lot of the un-compacted Proofs of Time before the node drops more into its lap. + +Note - The default settings may otherwise work but if the total effort is a little too much for whatever machine you are on you can also lower the `process_count:` from 3 to 2, or even 1, in the `timelord_launcher:` section. You know it is working if you see `VDF Client: Sent proof` in your logs at INFO level. + +# Launch timelord +chia start node timelord & +``` + + + + +:::warning +**DO NOT** overclock ASICs, overclocking diminishes the life of the ASIC! +Detailed information about the hw_vdf_client parameters can be found [here](/asic-cli). +::: + +#### ASIC Cluster Setup + +It is recommended to use three host machines for ASIC clusters in a setup similar to: + +``` + _____ ASIC 2 (ASIC software only, IP set to main machine) + / +Main Machine (ASIC 1) -------------------------- +(chia node, timelord-only, and ASIC software) \_____ ASIC 3 (ASIC software only, IP set to main machine) +``` + +For an ASIC cluster you will need to follow the below install steps on the main machine to include the chia node, timelord-only, and ASIC software processes are all being run on the main machine. +The additional ASIC hosts will only need the ASIC software installed (noted in the below install instructions). + +```bash +# Install packages +sudo apt-get update +sudo apt-get install ca-certificates curl gnupg + +# Add GPG key +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg + +# Set up repositories (first is for chia and second is for the hw vdf repo, for clusters the chia software is only needed on the main machine all other hosts need the hw vdf repo) +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chia.list > /dev/null +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/chiavdf-hw/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chiavdf-hw.list > /dev/null +sudo apt-get update + +# Install chia-blockchain and ASIC repos (for clusters the chia software is only needed on the main machine all other hosts need the hw vdf repo) +sudo apt-get install chia-blockchain +sudo apt-get install chiavdf-hw + +# Launch the ASIC timelord services (for clusters verify the IP address is correct and launch with only 1 VDF for each) +hw_vdf_client --ip 127.0.0.1 8000 3 + +# Launch timelord services in chia (for clusters only the main machine should be running the node and timelord services) +chia start node timelord-only +``` + + + + +### Installing a Timelord from Source + +:::info +On MacOS x86_64 and all Linux distributions, building a Timelord is as easy as running `chia start timelord &` in the virtual environment. You can also run `./vdf_bench square_asm 400000` once you've built Timelord to give you a sense of your optimal and unloaded ips. Each run of `vdf_bench` can be surprisingly variable and, in production, the actual ips you will obtain will usually be about 20% lower due to load of creating proofs. The default configuration for Timelords is good enough to just let you start it up. Set your log level to INFO and then grep for "Estimated IPS:" to get a sense of what actual ips your Timelord is achieving. +Detailed information about the hw_vdf_client parameters can be found [here](/asic-cli). +::: + +```bash +# Download chia-blockchain (for clusters the chia software is only needed on the main machine all other hosts need the hw vdf repo) +git clone https://github.com/Chia-Network/chia-blockchain -b latest --recurse-submodules + +# Change directory +cd chia-blockchain + +# Install dependencies +sh install.sh + +# Activate virtual environment +. ./activate + +# Initialize +chia init +. ./activate + +# Install timelord +sh install-timelord.sh + +# Start timelord (skip this step and proceed below if installing a bluebox or ASIC timelord) +chia start full_node timelord + +# Bluebox timelord setup +Once you build the Timelord with `sh install-timelord.sh` in the virtual environment, you will need to make two changes to `~/.chia/VERSION/config.yaml`. +- In the `timelord:` section, set `bluebox_mode:` to `True`. +- In the `full_node:` section and set `send_uncompact_interval:` to something greater than 0. We recommend `300` seconds there so that your Bluebox has some time to prove through a lot of the un-compacted Proofs of Time before the node drops more into its lap. + +Note - The default settings may otherwise work but if the total effort is a little too much for whatever machine you are on you can also lower the `process_count:` from 3 to 2, or even 1, in the `timelord_launcher:` section. You know it is working if you see `VDF Client: Sent proof` in your logs at INFO level. + +# ASIC timelord setup: install the timelord repo, run the timelord-only chia service, and run the ASIC software +## Install packages +sudo apt-get update +sudo apt-get install ca-certificates curl gnupg + +## Add GPG key +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg + +## Set up hw vdf repository (for clusters the chia software is only needed on the main machine all other hosts need the hw vdf repo) +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/chiavdf-hw/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chiavdf-hw.list > /dev/null +sudo apt-get update + +## Install ASIC repo +sudo apt-get install chiavdf-hw + +# Launch the ASIC timelord services (for clusters verify the IP address is correct and launch with only 1 VDF for each) +hw_vdf_client --ip 127.0.0.1 8000 3 + +## Launch the timelord-only chia service (for clusters only the main machine should be running the node and timelord services) +chia start node timelord-only + +``` + +--- + +## ASIC Timelord Systemd Setup + +Below is an example of a systemd service file to run the ASIC hw vdf processes. +NOTE - make sure to replace `USERNAME` with your system's username. + +```bash +# Create systemd service +sudo nano /etc/systemd/system/chiahw-vdf.service + +# Copy the data from below replacing USERNAME with your system's username +``` + +### Example ASIC systemd File + +```bash +[Unit] +Description=Chia HW VDF Service + +[Service] +Type=simple +ExecStart=/usr/bin/hw_vdf_client --ip 127.0.0.1 8000 3 +User=USERNAME +Group=USERNAME +LimitNOFILE=1048576 +LimitNPROC=1048576 +LimitCORE=infinity + +[Install] +WantedBy=multi-user.target +``` + +```bash +# Save and start the systemd service +CTRL+O # save the file +CTRL-X # exit the nano editor + +# Reload and start the systemd services +sudo systemctl daemon-reload +sudo systemctl enable chiahw-vdf.service +sudo systemctl start chiahw-vdf.service +sudo systemctl status chiahw-vdf.service +``` + +### Using the systemd Service + +Restart the ASIC systemd software: +`sudo systemctl restart chiahw-vdf.service` + +Stop the ASIC systemd software: +`sudo systemctl stop chiahw-vdf.service` + +Check status of the ASIC systemd software: +`sudo systemctl status chiahw-vdf.service` + +--- + +## Troubleshooting a Timelord + +For troubleshooting steps please refer to the documentation [here](/troubleshooting/timelords). + +--- + +## Timelord support + +Join Our [Discord](https://discord.gg/chia) and jump into the #support channel for support + +--- + +## Timelord FAQ + +### What are the hardware requirements for running a Timelord? + +There are no specific requirements as timelords are a fastest wins process. This means that those with higher end hardware are more likely to generate Proofs of Time than those with lower end hardware. +Currently, a modern gaming PC with 8 cores and 8 GB of RAM is recommended when running an ASIC or Bluebox timelord. With the release of ASIC timelords, software timelords will have a near impossible time competing. It is recommended to only run a software timelord for experimentation and learning purposes. + +### Can a Single ASIC Compete with an ASIC Cluster? + +The nature of timelords is to create three VDF chains, one can create the chains themselves in parallel (i.e. one on each ASIC) but one cannot break down the VDFs themselves to parallelize them. +This means that the ASIC cluster will always have an advantage but there are times when a single ASIC can reasonably compete. This almost always requires the block farming node to be closer in physical proximity to the single ASIC than to the ASIC cluster establishing a minor time advantage for the single ASIC + +### Can I Overclock the ASIC to Get More Performance or Higher IPS? + +While one can overclock the ASIC we very strongly recommend against doing such. Overclocking the ASICs will lead to diminishing longevity of the machine and only provides a minor increase in performance making it inefficient to overclock an ASIC. + +### What Voltage Should I Use for an ASIC Timelord? + +It is highly recommend to use the default `0.88` voltage. + +### What OS is Compatible with Running a Timelord? + +It is recommended to use a linux OS to run timelords as these are the most performant. +If running on a MAC, one can compile the chia repo from source and run the timelord services but this is currently only compatible with Intel chips and not compatible with the silicon chip. +Windows is not recommended, due to restrictions on how [MSVC](https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B) handles 128 bit numbers and how Python relies upon MSVC, it is not possible to build and run Timelords of all types on Windows. + +### What System Resources are most Important for an ASIC? + +The single thread speed is one of the most important factors for having a faster ASIC. + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/using-the-gui.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/using-the-gui.md index b5d2d007a2..b46bf62e0d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/using-the-gui.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/using-the-gui.md @@ -31,7 +31,7 @@ Enabling a passphrase is a recommended step for protecting your funds, but it on ## Syncing -Upon opening Chia, your wallet will need to sync. You'll need to see a green checkmark next to the **WALLET** label in the upper-right corner before seeing any tokens you have. +Upon opening Chia, your wallet will need to sync. Upon opening Chia, your wallet will need to sync. You'll need to see a green checkmark next to the **WALLET** label in the upper-right corner before seeing any tokens you have.

synced @@ -96,3 +96,11 @@ When acquiring NFTs or tokens, you may need to make an offer for them. Offers ar By using offers you are embracing the decentralized nature of the Chia blockchain. [Read more about offers](https://chialisp.com/offers). + +## Run Chia Services in the Background + +Starting in version 2.3.0, this is possible. When you attempt to close the application, the confirmation window will now display a checkbox. If you want to continue running your full node, harvester, farmer, etc after closing the GUI, be sure to check the checkbox, as demonstrated in the following image: + +

+ offers +

diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/wallet-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/wallet-guide.md index fcf1847d8f..14e9629470 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/wallet-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/getting-started/wallet-guide.md @@ -51,13 +51,13 @@ Assuming you don't have a wallet yet, click `CREATE A NEW WALLET KEY` (If you al

-You will be presented with a list of twenty-four words. This is your wallet's recovery phrase. These words are all that are needed to recover your wallet on a new computer. Write them down and store them in a safe place. The order of the words is also important. +You will be presented with a list of twenty-four words. This is your wallet's recovery phrase. These words are all that are needed to recover your wallet on a new computer. Write them down and store them in a safe place. The order of the words is important. This is your wallet's recovery phrase. These words are all that are needed to recover your wallet on a new computer. Write them down and store them in a safe place. The order of the words is also important. -You can also choose a custom name for your wallet. Click `NEXT` when you are finished. +You can also choose a custom name for your wallet. Click NEXT when you are finished. Click `NEXT` when you are finished. :::warning -If someone obtains a copy of these words, they can steal your entire wallet, including all of its funds. Be sure to store your recovery phrase in a safe place. +If someone obtains a copy of these words, they can steal your entire wallet, including all of its funds. Be sure to store your recovery phrase in a safe place. Be sure to store your recovery phrase in a safe place. ::: @@ -91,7 +91,7 @@ Chia Asset Tokens (CATs) are fungible assets on Chia's blockchain. In Chia parla
manage token list -
+

2. The Chia reference wallet comes with a few included CATs, but most will need to be entered manually. If you want to add one of the included CATs, click the slider next to the CAT you would like to add. @@ -99,14 +99,14 @@ Chia Asset Tokens (CATs) are fungible assets on Chia's blockchain. In Chia parla
add token -
+

3. If your new CAT is not included in the reference wallet, you will need to obtain its Asset ID (TAIL). There are multiple websites that provide a listing of CATs and their IDs. One such site is [spacescan.io](https://www.spacescan.io). Simply browse to the website, then search for your CAT. For example, here is a search for "dexie bucks":
search for dexie bucks -
+

In addition to CATs, Spacescan provides a listing of NFTs. In certain cases, such as with Dexie Bucks, there are CAT _and_ NFT collections with the same name. In this case, be sure to click on `CAT2`, as in the above image. @@ -115,21 +115,21 @@ The result will show you the details of the CAT you selected, including its ID.
copy dexie bucks ID -
+

It is recommended that you check with another source of truth to make sure you have the correct ID. Another website that provides a listing of CATs and their IDs is [taildatabase.com](https://www.taildatabase.com/). Browse to this site, click the `Explore` menu, and search for your CAT. The name should appear in the search results:
taildatabase dexie bucks search -
+

Some information about the CAT will appear, including its Asset ID, as highlighted here:
taildatabase dexie bucks asset ID -
+

Copy this ID and continue to the next step. @@ -144,7 +144,7 @@ If someone sends you an Asset ID (TAIL), do not assume it is correct. Instead, d
One Meeellion CATs -
+

Your new CAT will now appear in the "Tokens" list in your wallet. @@ -157,7 +157,7 @@ For our first example Offer, we will offer 1 XCH in exchange for the new CAT.
create an offer -
+

2. Next, fill in the details of the Offer. By default, the Offer will be set to expire after 7 days. This is likely fine in most cases. (If an Offer never expires, there is a chance it will be taken as arbitrage long after the maker has forgotten about it.) However, feel free to enter a different expiration time if desired. @@ -168,14 +168,14 @@ After all of the details have been filled in, click `CREATE OFFER`:
fill in offer details -
+

3. If anyone acquires this Offer and it is still valid, they will be able to take it. Click the `I UNDERSTAND` button and the Offer will be created:
confirm offer -
+

3. At this point, the Offer has been created locally. However, until you share it, it is unlikely that anyone will know it exists. Feel free to email the Offer file, share it on social media, etc. The Offer file does not contain any sensitive data. Whoever sees it will only have two options: take it or ignore it. @@ -188,14 +188,14 @@ _ Spacescan -- an explorer and bulletin board \* Finally, you can save the file
distribute offer -
+

4. The Offer will now appear as `Pending Accept`, and the amount of time (if any) until it expires will also be shown:
offer pending status -
+

Congratulations! You have created an Offer. A few things to note: @@ -215,73 +215,73 @@ This example will use a different computer to accept the Offer that was created
One Meeellion CATs -
+

2. Click `Offers`, then view the Offer by either loading, dragging/dropping, or pasting the file:
view offer -
+

3. In this case, the Offer will expire in 6 days. The Taker must give 1000 CATs in exchange for 1 TXCH. The Maker has included a blockchain fee, and the Taker has the option of adding to this fee if desired. If the terms are acceptable, click `ACCEPT OFFER`:
accept offer -
+

4. You will need to confirm that you actually want to accept the Offer, which will initiate an on-chain transaction:
verify acceptance of offer -
+

5. The Offer has been accepted. Click `OK`:
offer accepted -
+

6. While the blockchain transaction is pending, you will see this status in the `Offers you accepted` panel:
offer pending confirm -
+

7. Meanwhile, the `Tokens` screen will show the pending XCH and CAT amounts:
1 XCH incoming -
+

1000 CATs outgoing -
+

8. After the transaction has been confirmed (typically 1-3 minutes), the Offer's status will be updated to `Confirmed`:
plus 1 XCH -
+

9. The final XCH and CAT balances will then be reflected in the `Tokens` screen:
minus 1000 CATs -
+

offer pending status -
+

--- @@ -296,17 +296,17 @@ Click the three dots in the "Actions" column:
Pending Accept -
+

-2. Click "Cancel Offer". +2. Click "Cancel Offer".
Cancel Offer -
+

-3. The "Cancel Offer" dialog will appear. The default option is to cancel on the blockchain, as shown in the red circle in the image below. +3. The "Cancel Offer" dialog will appear. The default option is to cancel on the blockchain, as shown in the red circle in the image below. This option will use your wallet to spend the coin(s) you had offered, and create new coins of the same type and value. This process does not involve taking the other end of the Offer, so you will not receive any funds of the type you had requested. The end result is that your wallet's balance will be the same as it was before you made the Offer (minus any transaction fees). @@ -314,30 +314,30 @@ The advantage of canceling in this manner is that it ensures that nobody can acc
Cancel on blockchain -
+

-4. If you uncheck the checkbox, your wallet will un-reserve the coins for your Offer. However, nothing will be recorded on the blockchain. If you have copied your Offer file elsewhere, someone could still accept it. +4. If you uncheck the checkbox, your wallet will un-reserve the coins for your Offer. However, nothing will be recorded on the blockchain. If you have copied your Offer file elsewhere, someone could still accept it. The advantages of this option are that it will cancel your Offer instantly, and there's no need to include a fee.
Cancel off chain -
+

-5. If you left the checkbox checked in the previous step, your Offer will enter the "Pending Cancel" state while the cancellation is being recorded on the blockchain. This could take several minutes. +5. If you left the checkbox checked in the previous step, your Offer will enter the "Pending Cancel" state while the cancellation is being recorded on the blockchain. This could take several minutes.
Pending Cancel -
+

-6. When your order has been successfully canceled, it will enter the "Cancelled" state. Your funds are now available in your wallet. +6. When your order has been successfully canceled, it will enter the "Cancelled" state. Your funds are now available in your wallet.
Cancelled -
+

--- @@ -350,28 +350,28 @@ You can also create Offers to buy or sell NFTs. While it is possible to select N
Cancelled -
+

2. In this case, both of the NFTs are selected. Next, click `ACTIONS` and `Create Offer`:
Cancelled -
+

3. The `Offer Maker` dialog will appear. Fill in any additional details for your Offer (be sure to request something!), and click `CREATE OFFER`:
Cancelled -
+

3. Share the Offer as you would with a CAT Offer. After the Offer has been created, the NFTs being offered will appear in the Offer summary:
Cancelled -
+

--- @@ -384,21 +384,21 @@ You can also swap NFTs for other NFTs, just like trading cards.
Multi NFT swap -
+

2. When you are satisfied with terms of the Offer, click `CREATE OFFER`:
Cancelled -
+

3. After the Offer has been created, the assets to be trade will be displayed in the summary, just as with other Offers:
Cancelled -
+

--- @@ -413,42 +413,42 @@ This example will continue with the same NFT-NFT Offer from the last section.
Share on Dexie -
+

2. Be sure to verify that the Offer is correct; after it is shared publicly, someone could accept it:
Share Offer -
+

3. Click `NOTIFY CURRENT OWNER`:
Notify current owner -
+

4. You have the option to add a transaction fee for the notification. You can also choose whether to allow counter offers:
Send message -
+

5. A new offer coin will be created. If the owner of the NFT you would like to acquire is using the reference wallet, the wallet will notice this new coin and examine its contents. A new notification will appear in the owner's wallet. Click the notification bell:
Incoming notification -
+

6. A summary of the Offer will appear. Click the summary to see the details of the Offer:
View Offer -
+

--- @@ -497,6 +497,7 @@ Let's say a Maker has wallets for XCH and CKC, with no money in either of them.
0 CKC wallet
+
The maker attempts to make an ambitious offer: 100 XCH for 1 million CKC. @@ -570,6 +571,7 @@ There is a warning dialog about the unknown cat, after which the Offer is confir
Unknown CAT success
+
Notice that the Offer file was named `0.25_Shibe_for_0.1_XCH.offer`, but the file name itself does _not_ dictate the contents of the Offer. The Taker may have inadvertently accepted an Offer for a worthless token! @@ -604,6 +606,7 @@ Let's say a Maker has 0.1 XCH and 1 USDS:
1 USDS in wallet
+
The Maker offers 0.1 XCH in exchange for 10 USDS: @@ -635,6 +638,7 @@ After the Offer has been canceled, a Taker notices the Offer file and decides to
Confirm a canceled offer
+
Later, the Maker notices that the Offer has gone through, despite having been canceled: @@ -645,6 +649,7 @@ Later, the Maker notices that the Offer has gone through, despite having been ca
Post-offer 11 USDS
+
If the Offer had been canceled on-chain, the reserved coins would have been spent. At that point, even if someone else had gotten access to the Offer file, the Offer itself would've been invalid. @@ -667,6 +672,7 @@ For example, let's say a Maker has 1 XCH and 0 USDS:
0 USDS in wallet
+
The Maker creates an Offer of 0.1 XCH for 10 USDS. @@ -683,10 +689,12 @@ This is viewable in the offer's details:
One coin used for offer +
Scroll to the bottom to view coins reserved for the Offer.
+
While the Offer is pending, the Maker attempts to send 0.1 XCH to another address. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-abstract.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-abstract.md index dacb226e69..81e963a3a5 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-abstract.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-abstract.md @@ -18,4 +18,4 @@ slug: /green-paper-abstract ### 先前版本共识绿皮书 -为了提供历史背景，绿皮书的先前版本讨论了一种从未实现的共识，可以在这里查看：[先前绿皮书](/files/Precursor-ChiaGreenPaper.pdf)。 +In order to provide historical context, the Green Paper's previous version that discusses a precursor consensus which was never implemented is available here for viewing: [Precursor Green Paper](https://docs.chia.net/assets/files/Precursor-ChiaGreenPaper-82cb50060c575f3f71444a4b7430fb9d.pdf). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-appendix.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-appendix.md index 19ecff6b0a..2e86b7f27f 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-appendix.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-appendix.md @@ -57,13 +57,22 @@ To prevent grinding attacks, we need our PoSpace to be unique as defined below. A PoSpace is unique if for any identity $pk$ and any challenge $c$ there is exactly one proof, i.e., $$ -\begin{aligned} &\forall N,pk,c,\\ &\left|\{\sigma\ :\ \left({{\sf PoSpace.verify}}(\sigma)={\sf accept}\right)\wedge \left( (\sigma.N,\sigma.pk,\sigma.c)=(N,pk,c)\right)\}\right|= 1 \end{aligned} +\begin{aligned} +&\forall N,pk,c,\\ +&\left|\{\sigma\ :\ \left({{\sf PoSpace.verify}}(\sigma)={\sf accept}\right)\wedge \left( (\sigma.N,\sigma.pk,\sigma.c)=(N,pk,c)\right)\}\right|= 1 +\end{aligned} $$ We call a PoSpace _weakly_ unique if the _expected_ number of proofs is close to $1$, i.e., $$ -\begin{aligned} &\forall N,pk,c,\\ &{\mathrm E}_{c\gets \{0,1\}^w}\left[|\{\sigma : \left({{\sf PoSpace.verify}}(\sigma)={\sf accept}\} \right) \wedge \left((\sigma.N,\sigma.pk,\sigma.c)=(N,pk,c)\right) |\right]\\ &\approx 1 \end{aligned} +\begin{aligned} +&\forall N,pk,c,\\ +&{\mathrm E}_{c\gets \{0,1\}^w}\left[|\{\sigma : \left({{\sf PoSpace.verify}}(\sigma)={\sf accept}\} \right) +\wedge \left((\sigma.N,\sigma.pk,\sigma.c)=(N,pk,c)\right) +|\right]\\ +&\approx 1 +\end{aligned} $$ For weakly unique PoSpace we assume that whenever there is more than one proof for a given challenge which passes verification, ${\sf PoSpace.prove}(S,c)$ outputs all of them. @@ -83,7 +92,8 @@ $$ Note that if we model ${\sf H}$ as a random function, then $f,g$ are also random functions. On a challenge $y\in L$ the prover must answer with a tuple $$ -id,(x,x')\qquad\textrm{ where }\qquad x\neq x', f(x)=f(x'), g(x,x')=y +id,(x,x')\qquad\textrm{ where }\qquad +x\neq x', f(x)=f(x'), g(x,x')=y $$ if it exists. In this construction, for roughly a $(1-1/e)\approx 0.632$ fraction of the challenges $y\in L$ there will be at least one proof, and the expected number of proofs is $1$ (so it is a weakly unique PoSpace). @@ -138,7 +148,8 @@ $$ The two security properties we require are -**uniqueness:** It is hard to come up with any statement and an accepting proof for a wrong output. More precisely, it is computationally difficult to find any $\tau'$ where for $\tau\gets {\sf VDF.solve}(\tau'.c,\tau'.t)$ we have +**uniqueness:** +It is hard to come up with any statement and an accepting proof for a wrong output. More precisely, it is computationally difficult to find any $\tau'$ where for $\tau\gets {\sf VDF.solve}(\tau'.c,\tau'.t)$ we have $$ {\sf VDF.verify}(\tau')={\sf accept}\quad\textrm{ and }\quad\tau.y\neq \tau'.y\ . @@ -146,18 +157,19 @@ $$ Note that we only need $\tau.y$ (but not $\tau.\pi$) to be unique, i.e., the proof $\tau.\pi$ showing that $\tau.y$ is the correct value can be malleable. This seems sufficient for all applications of VDFs, but let us mention that in the [Pie19b; Wes20] VDFs discussed below also $\tau.\pi$ is unique. -**sequentiality:** Informally, sequentiality states that for any $t$, an adversary ${\cal A}$ who makes less than $t$ sequential steps will not find an accepting proof on a random challenge. I.e., for some tiny $\epsilon$ +**sequentiality:** +Informally, sequentiality states that for any $t$, an adversary ${\cal A}$ who makes less than $t$ sequential steps will not find an accepting proof on a random challenge. I.e., for some tiny $\epsilon$ $$ \hspace{-1cm} - \Pr[{\sf VDF.verify}(\tau)={\sf accept}\ \wedge \ \tau.c=c\ \wedge\ \tau.t=t \ :\ c\stackrel{rand}{\gets}\{0,1\}^w,\tau\gets{\cal A}(c,t)]\le \epsilon + \Pr[{\sf VDF.verify}(\tau)={\sf accept}\ \wedge \ \tau.c=c\ \wedge\ \tau.t=t \ :\ c\stackrel{rand}{\gets}\{0,1\}^w,\tau\gets{\cal A}(c,t)]\le \epsilon $$ Let us stress that ${\cal A}$ is only bounded by the number of _sequential_ steps, but they can use high parallelism. Thus the VDF output cannot be computed faster by adding parallelism beyond what can be used to speed up a single step of the VDF computation. ### A.3.1 The [Pie19b, Wes20] VDFs -The VDFs proposed in \[Pie19b; Wes20\] (see [BBBF18a] for an overview of those constructions) are both based on squaring in a group of unknown order, for concreteness let the group be $\mathbb{Z}_N^*$ where $N=pq$ is the product of two large primes $p,q$. On input ${\sf VDF.solve}(c,t)$ one would first map the challenge $c$ on a group element, say as $x_c:= hash(c)\bmod N$, and the output is $(y,\pi)$ with $y=x_c^{2^t}\bmod N$. This $y$ can be computed by squaring $x_c$ sequentially $t$ times $x_c\rightarrow x_c^2\rightarrow x_c^{2^2}\rightarrow \cdots \rightarrow x_c^{2^t}$, and it is conjectured that there is no shortcut to this computation if one doesn't know the factorization of $N$. +The VDFs proposed in [Pie19b; Wes20] (see [BBBF18a] for an overview of those constructions) are both based on squaring in a group of unknown order, for concreteness let the group be $\mathbb{Z}_N^*$ where $N=pq$ is the product of two large primes $p,q$. On input ${\sf VDF.solve}(c,t)$ one would first map the challenge $c$ on a group element, say as $x_c:= hash(c)\bmod N$, and the output is $(y,\pi)$ with $y=x_c^{2^t}\bmod N$. This $y$ can be computed by squaring $x_c$ sequentially $t$ times $x_c\rightarrow x_c^2\rightarrow x_c^{2^2}\rightarrow \cdots \rightarrow x_c^{2^t}$, and it is conjectured that there is no shortcut to this computation if one doesn't know the factorization of $N$. The VDFs from [Pie19b; Wes20] differ in how the proof $\pi$ that certifies that $y=x_c^{2^t}\bmod N$ is defined. The proof in [Pie19b] is shorter ($1$ vs. $\log(T)$ elements), but soundness of the proof requires an additional assumption (that taking random roots is hard). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-introduction.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-introduction.md index a0661ab3d5..7390890b37 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-introduction.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-introduction.md @@ -13,7 +13,7 @@ The **$\textsf{Chia}$ network** ([chia.net](https://chia.net/)) is a permission
Figure 1: Illustration of one slot (taking around 10 minutes) of the Chia blockchain. For illustration the slot has just 16 (instead 64) signage points and only 4 blocks (the actual chain has a target of 32).
-As mentioned, $\textsf{Chia}$ is basically what's called a _longest-chain_ protocol in the literature [BNPW19; BDK+19]. This notion captures blockchain protocols that borrow the main ideas from the Bitcoin blockchain: the parties (called miners in Bitcoin and farmers in Chia) that dedicate resources (hashing power in Bitcoin, disk space in Chia) towards securing the blockchain just need to +As mentioned, $\textsf{Chia}$ is basically what's called a _longest-chain_ protocol in the literature [BNPW19; BDK+19]. This notion captures blockchain protocols that borrow the main ideas from the Bitcoin blockchain: the parties (called miners in Bitcoin and farmers in Chia) that dedicate resources (hashing power in Bitcoin, disk space in Chia) towards securing the blockchain just need to This notion captures blockchain protocols that borrow the main ideas from the Bitcoin blockchain: the parties (called miners in Bitcoin and farmers in Chia) that dedicate resources (hashing power in Bitcoin, disk space in Chia) towards securing the blockchain just need to 1. listen to the (P2P) network to learn about progress of the chain and to collect transactions. @@ -23,7 +23,7 @@ As mentioned, $\textsf{Chia}$ is basically what's called a _longest-chain_ prot No other coordination or communication amongst the parties is required. In particular, as the miners in Bitcoin, the farmers in $\textsf{Chia}$ only need to speak up once they find a block and want it to be included in the chain. -Constructing a secure permissionless blockchain using proofs of space is much more challenging than using proofs of work. In particular, a secure (under dynamic availability) longest-chain protocol based on proofs of space alone does not exist [BP22], so Chia's _proofs of space and time_ (PoST) consensus protocol, apart from farmers providing disk space, additionally relies on so called timelords who evaluate verifiable delay functions (VDFs). Figure 2 gives an overview of the formal security proofs and more informal arguments outlined in this document. +Constructing a secure permissionless blockchain using proofs of space is much more challenging than using proofs of work. Constructing a secure permissionless blockchain using proofs of space is much more challenging than using proofs of work. In particular, a secure (under dynamic availability) longest-chain protocol based on proofs of space alone does not exist [BP22], so Chia's _proofs of space and time_ (PoST) consensus protocol, apart from farmers providing disk space, additionally relies on so called timelords who evaluate verifiable delay functions (VDFs). Figure 2 gives an overview of the formal security proofs and more informal arguments outlined in this document. Figure 2 gives an overview of the formal security proofs and more informal arguments outlined in this document.
Diagram of Chia security and arguments @@ -34,17 +34,13 @@ Constructing a secure permissionless blockchain using proofs of space is much mo The Bitcoin blockchain is secure [GKL15] as long as the hashing power $hash_h$ (measured in hashes per second) contributed by honest parties is larger than the hashing power $hash_a$ available to an adversary, i.e., -$$ -hash_h > hash_a -$$ +$$ hash_h > hash_a $$
eq.(1)
Similarly, the security of $\textsf{Chia}$ depends on the amount of space $space_h$ and $space_a$ controlled by the honest parties and the adversary, respectively. Additionally, the speed $vdf_h$ and $vdf_a$ (measured in steps per second) of the VDFs run by the fastest honest timelord and the adversary are relevant. With these definitions, -$$ -\textrm{{\sf Chia}\ is provably secure if : } space_h\cdot vdf_h > space_a \cdot vdf_a \cdot 1.47 -$$ +$$ \textrm{{\sf Chia}\ is provably secure if : } space_h\cdot vdf_h > space_a \cdot vdf_a \cdot 1.47 $$
eq.(2)
@@ -56,9 +52,7 @@ This assumption comes at a prize: there's a $1.47$ factor by which the adversari The bound in eq.(1) is not tight in the sense that we don't have an attack that works if we replace "$>$" with "$<$". We have an attack assuming giving the adversary a slightly lower boosting factor of $1.34$ -$$ -\textrm{double spending in {\sf Chia}\ possible if : }space_h\cdot vdf_h < space_a \cdot vdf_a \cdot 1.34 -$$ +$$ \textrm{double spending in {\sf Chia}\ possible if : }space_h\cdot vdf_h < space_a \cdot vdf_a \cdot 1.34 $$
eq.(3)
@@ -70,9 +64,7 @@ A contribution of this writeup is a modular approach towards achieving secure lo In Bitcoin each block contains the hash of the previous block. If two blocks are found at roughly the same time, so there was no time for the block that was found first to propagate to the miner that found the second, they will refer to the same block, and only one can be added to the chain. The other will be "orphaned" and does not contribute towards securing the blockchain. The fraction of orphaned blocks depends on the network delay (the smaller the delay the fewer orphans) and the block-arrival time (fewer blocks per minute decrease the probability of orphans). Taking this into account, the security statement for Bitcoin from eq.(1) should be augmented to: -$$ -hash_h \cdot \left(1-\frac{network\ delay}{block\ arrival\ time}\right)> hash_a -$$ +$$ hash_h \cdot \left(1-\frac{network\ delay}{block\ arrival\ time}\right)> hash_a $$
eq.(4)
@@ -176,7 +168,7 @@ A block $\beta=\{\beta_F,\beta_T\}$ is made of two parts, the foliage block $\be - A timelord computes the ${\cal RC},{\cal CC},{\sf i}{\cal CC},{\cal FC}$ chains and broadcasts relevant values to the network. This includes signage points ${\sf rc\_sp}$ and ${\sf cc\_sp}$ which are the values of the ${\cal RC}$ and ${\cal CC}$ chains (together with a proof that these values are on the VDF chains) once every $9.375$ seconds. -- A farmer who receives these _signage points_ ${\sf rc\_sp}$ and ${\sf cc\_sp}$ checks whether these points are of interest (i.e., on the heaviest known chain) and all the VDF proofs verify. Next, for each of their plots, they use ${\sf cc\_sp}$ as a challenge to compute a PoSpace $\sigma$. Then they check whether $\sigma$ satisfies a winning condition that allows to produce a block. +- A farmer who receives these _signage points_ ${\sf rc\_sp}$ and ${\sf cc\_sp}$ checks whether these points are of interest (i.e., on the heaviest known chain) and all the VDF proofs verify. Next, for each of their plots, they use ${\sf cc\_sp}$ as a challenge to compute a PoSpace $\sigma$. Then they check whether $\sigma$ satisfies a winning condition that allows to produce a block. Next, for each of their plots, they use ${\sf cc\_sp}$ as a challenge to compute a PoSpace $\sigma$. Then they check whether $\sigma$ satisfies a winning condition that allows to produce a block. If a winning PoSpace $\sigma$ is found, the farmer creates a signature $\mu_{\sf rc\_sp}$ of ${\sf rc\_sp}$ (that verifies under the $pk$ associated with $\sigma$) and a foliage block $\beta_F$ and then gossips the block $\beta=\{\beta_F,\beta_T=\{\sigma,\mu_{\sf rc\_sp}\}\}$. @@ -188,7 +180,7 @@ A block $\beta=\{\beta_F,\beta_T\}$ is made of two parts, the foliage block $\be (${\sf i}{\cal CC}$) For some extra security, the timelord doesn't simply wait till the end of the slot to infuse the signature, but a third VDF is used to fork from ${\cal CC}$ at the infusion point by infusing $\mu_{\sf rc\_sp}$ into ${\cal CC}$, and this fork, called the infused challenge chain ${\sf i}{\cal CC}$, is then infused back to ${\cal CC}$ at the end of the slot. - (${\cal FC}$) Iff the signage point of this block is later than the infusion point of the last _transaction block_, then this block is also a transaction block. Only in this case its foliage $\beta_F$ is appended to the foliage (hash) chain ${\cal FC}$, and this block becomes a "transaction block". + (${\cal FC}$) Iff the signage point of this block is later than the infusion point of the last _transaction block_, then this block is also a transaction block. Only in this case its foliage $\beta_F$ is appended to the foliage (hash) chain ${\cal FC}$, and this block becomes a "transaction block". Only in this case its foliage $\beta_F$ is appended to the foliage (hash) chain ${\cal FC}$, and this block becomes a "transaction block". ## 1.8 Space Oddities @@ -196,7 +188,7 @@ When constructing a proof of stake or proof or a space based longest-chain proto ### 1.8.1 Sized vs. Unsized -A key difference between stake and work is the fact that in a stake based chain we know the amount of the resource available for mining, while for an external resource like work or space this is no longer the case. Lewis-Pye and Roughgarden [Lew21; LR21] formalize this as the _sized_ vs. _unsized_ setting and prove some fundamental differences between them. The main result in [LR21] shows that _certificates_ which "provide incontrovertible proof of block confirmation", only exist in the sized setting, i.e., for PoStake but not PoWork blockchains. +A key difference between stake and work is the fact that in a stake based chain we know the amount of the resource available for mining, while for an external resource like work or space this is no longer the case. Lewis-Pye and Roughgarden [Lew21; LR21] formalize this as the _sized_ vs. _unsized_ setting and prove some fundamental differences between them. A key difference between stake and work is the fact that in a stake based chain we know the amount of the resource available for mining, while for an external resource like work or space this is no longer the case. Lewis-Pye and Roughgarden [Lew21; LR21] formalize this as the _sized_ vs. _unsized_ setting and prove some fundamental differences between them. The main result in [LR21] shows that _certificates_ which "provide incontrovertible proof of block confirmation", only exist in the sized setting, i.e., for PoStake but not PoWork blockchains. In their framework _space_ and also _space and time_ (i.e., the available space multiplied with the speed of the available VDFs) as used in $\textsf{Chia}$ are an unsized resource, so we can't hope to get certificates. @@ -210,7 +202,7 @@ To prevent such attacks some chain require parties to delete old keys, but it's ### 1.8.3 Replotting -A subtle but important difference between stake and space is the fact that space allows for _replotting_ which has no analogue in the stake setting: Given a challenge $c$, a space farmer controlling a plot $S$ of size $N$ can _efficiently_ compute _one_ proof $\sigma \gets {\sf PoSpace.prove}(S,c)$. This is analogous to the stake based setting, but unlike in the stake setting, the farmer can _inefficiently_ compute _multiple_ proofs for challenge $c$ by repeatedly creating fresh plots and computing one proof with each of them. +A subtle but important difference between stake and space is the fact that space allows for _replotting_ which has no analogue in the stake setting: Given a challenge $c$, a space farmer controlling a plot $S$ of size $N$ can _efficiently_ compute _one_ proof $\sigma \gets {\sf PoSpace.prove}(S,c)$. This is analogous to the stake based setting, but unlike in the stake setting, the farmer can _inefficiently_ compute _multiple_ proofs for challenge $c$ by repeatedly creating fresh plots and computing one proof with each of them. This is analogous to the stake based setting, but unlike in the stake setting, the farmer can _inefficiently_ compute _multiple_ proofs for challenge $c$ by repeatedly creating fresh plots and computing one proof with each of them. We refer to attacks exploiting this fact as _replotting attacks_. The most basic design choice to harden a chain against replotting attacks is to make sure that challenges arrive at a sufficiently high rate so that substantial replotting in-between two challenges is not feasible. Moreover the plot filter (which dictates what fraction of plots must be accessed with every challenge) cannot be chosen too aggressively as more aggressive filters makes potential replotting attacks easier. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-references.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-references.md index 3a6cf430d8..46313aac7f 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-references.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/green-paper-references.md @@ -6,35 +6,35 @@ slug: /green-paper-references # References -| Identifier | Publication | -| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| AAC+17 | Hamza Abusalah, Joël Alwen, Bram Cohen, Danylo Khilko, Krzysztof Pietrzak, and Leonid Reyzin. Beyond Hellman’s time-memory trade-offs with applications to proofs of space. In Tsuyoshi Takagi and Thomas Peyrin, editors, _Advances in Cryptology - ASI- ACRYPT 2017 - 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part II_, volume 10625 of _Lecture Notes in Computer Science_, pages 357–379. Springer, 2017. | -| BBBF18 | Dan Boneh, Joseph Bonneau, Benedikt Bu ̈nz, and Ben Fisch. Verifiable delay functions. In Hovav Shacham and Alexandra Boldyreva, editors, _Advances in Cryptology - CRYPTO 2018 - 38th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 19-23, 2018, Proceedings, Part I, volume 10991 of Lecture Notes in Computer Science_, pages 757–788. Springer, 2018. | -| BBF18 | Dan Boneh, Benedikt Bu ̈nz, and Ben Fisch. A survey of two verifi- able delay functions. _IACR Cryptol. ePrint Arch._, page 712, 2018. | -| BDK+19 | Vivek Bagaria, Amir Dembo, Sreeram Kannan, Sewoong Oh, David Tse, Pramod Viswanath, Xuechao Wang, and Ofer Zeitouni. Proof- of-stake longest chain protocols: Security vs predictability. 2019. | -| BGK+18 | Christian Badertscher, Peter Gazi, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas. Ouroboros genesis: Composable proof-of-stake blockchains with dynamic availability. In David Lie, Mohammad Mannan, Michael Backes, and XiaoFeng Wang, editors, _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018_, pages 913–930. ACM, 2018. | -| BNPW19 | Jonah Brown-Cohen, Arvind Narayanan, Alexandros Psomas, and S. Matthew Weinberg. Formal barriers to longest-chain proof-of-stake protocols. In Anna Karlin, Nicole Immorlica, and Ramesh Johari, editors, _Proceedings of the 2019 ACM Conference on Economics and Computation, EC 2019, Phoenix, AZ, USA, June 24-28, 2019_, pages 459–473. ACM, 2019. | -| BP22 | Mirza Ahad Baig and Krzysztof Pietrzak. On the existence of proof of space longest chain protocols (working title), 2022. 2022. Manuscript in preparation. | -| CKWN16 | Miles Carlsten, Harry A. Kalodner, S. Matthew Weinberg, and Arvind Narayanan. On the instability of bitcoin without the block reward. In Edgar R. Weippl, Stefan Katzenbeisser, Christopher Kruegel, Andrew C. Myers, and Shai Halevi, editors, _Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016_, pages 154–167. ACM, 2016. | -| CP19 | Bram Cohen and Krzysztof Pietrzak. The chia network blockchain. 2019. | -| DFKP15 | Stefan Dziembowski, Sebastian Faust, Vladimir Kolmogorov, and Krzysztof Pietrzak. Proofs of space. In Rosario Gennaro and Matthew Robshaw, editors, _Advances in Cryptology - CRYPTO 2015 - 35th Annual Cryptology Conference, Santa Barbara, CA, USA, August 16-20, 2015, Proceedings, Part II, volume 9216 of Lecture Notes in Computer Science_, pages 585–605. Springer, 2015. | -| DKT21 | Soubhik Deb, Sreeram Kannan, and David Tse. Posat: Proof-of-work availability and unpredictability, without the work. In Nikita Borisov and Claudia Diaz, editors, _Financial Cryptography and Data Security - 25th International Conference, FC 2021, Virtual Event, March 1-5, 2021, Revised Selected Papers, Part II, volume 12675 of Lecture Notes in Computer Science_, pages 104–128. Springer, 2021. | -| DW13 | Christian Decker and Roger Wattenhofer. Information propagation in the bitcoin network. In _13th IEEE International Conference on Peer-to-Peer Computing, IEEE P2P 2013, Trento, Italy, September 9-11, 2013_, Proceedings, pages 1–10. IEEE, 2013. | -| EFKP20 | Naomi Ephraim, Cody Freitag, Ilan Komargodski, and Rafael Pass. Continuous verifiable delay functions. In Anne Canteaut and Yuval Ishai, editors, _Advances in Cryptology - EUROCRYPT 2020 - 39th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Zagreb, Croatia, May 10-14, 2020, Proceedings, Part III_, volume 12107 of _Lecture Notes in Computer Science_, pages 125–154. Springer, 2020. | -| ES18 | Ittay Eyal and Emin Gu ̈n Sirer. Majority is not enough: bitcoin mining is vulnerable. _Commun_. ACM, 61(7):95–102, 2018. | -| FZ17 | Lei Fan and Hong-Sheng Zhou. iching: A scalable proof-of-stake blockchain in the open setting (or, how to mimic nakamoto’s design via proof-of-stake). _IACR Cryptol. ePrint Arch._, page 656, 2017. | -| GKL15 | Juan A. Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol: Analysis and applications. In Elisabeth Oswald and Marc Fischlin, editors, _Advances in Cryptology - EUROCRYPT 2015 - 34th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Sofia, Bulgaria, April 26-30, 2015, Proceedings, Part II_, volume 9057 of _Lecture Notes in Computer Science_, pages 281–310. Springer, 2015. | -| GKR18 | Peter Gazi, Aggelos Kiayias, and Alexander Russell. Stake-bleeding attacks on proof-of-stake blockchains. In _Crypto Valley Conference on Blockchain Technology, CVCBT 2018, Zug, Switzerland, June 20-22, 2018_, pages 85–92. IEEE, 2018. | -| Hel80 | Martin E. Hellman. A cryptanalytic time-memory trade-off. _IEEE Trans. Inf. Theory_, 26(4):401–406, 1980. | -| Lew21 | Andrew Lewis-Pye. Byzantine generals in the permissionless setting. _CoRR_, abs/2101.07095, 2021. | -| LR21 | Andrew Lewis-Pye and Tim Roughgarden. How does blockchain security dictate blockchain implementation? In Yongdae Kim, Jong Kim, Giovanni Vigna, and Elaine Shi, editors, _CCS ’21: 2021 ACM SIGSAC Conference on Computer and Communications Security, Virtual Event, Republic of Korea, November 15 - 19, 2021_, pages 1006–1019. ACM, 2021. | -| Pie19a | Krzysztof Pietrzak. Proofs of catalytic space. In Avrim Blum, editor, _10th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 10-12, 2019, San Diego, California, USA_, volume 124 of LIPIcs, pages 59:1–59:25. Schloss Dagstuhl - Leibniz- Zentrum für Informatik, 2019. | -| Pie19b | Krzysztof Pietrzak. Simple verifiable delay functions. In Avrim Blum, editor, 1*0th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 10-12, 2019, San Diego, California, USA*, volume 124 of LIPIcs, pages 60:1–60:15. Schloss Dagstuhl - Leibniz-Zentrum fu ̈r Informatik, 2019. | -| PKF+18 | Sunoo Park, Albert Kwon, Georg Fuchsbauer, Peter Gazi, Joël Alwen, and Krzysztof Pietrzak. Spacemint: A cryptocurrency based on proofs of space. In Sarah Meiklejohn and Kazue Sako, editors, _Financial Cryptography and Data Security - 22nd International Conference, FC 2018, Nieuwpoort, Cura ̧cao, February 26 - March 2, 2018, Revised Selected Papers_, volume 10957 of _Lecture Notes in Computer Science_, pages 480–499. Springer, 2018. | -| PS17 | Rafael Pass and Elaine Shi. The sleepy model of consensus. In Tsuyoshi Takagi and Thomas Peyrin, editors, _Advances in Cryptology - ASIACRYPT 2017 - 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part II_, volume 10625 of _Lecture Notes in Computer Science_, pages 380–409. Springer, 2017. | -| SNM+21 | Caspar Schwarz-Schilling, Joachim Neu, Barnab ́e Monnot, Aditya Asgaonkar, Ertem Nusret Tas, and David Tse. Three attacks on proof-of-stake ethereum. _IACR Cryptol. ePrint Arch._, page 1413, 2021. | -| SSZ15 | Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar. Optimal selfish mining strategies in bitcoin. _CoRR_, abs/1507.06183, 2015. | -| Wes20 | Benjamin Wesolowski. Efficient verifiable delay functions. _J. Cryptol._, 33(4):2113–2147, 2020. | +| Identifier | Publication | +| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| AAC+17 | Hamza Abusalah, Joël Alwen, Bram Cohen, Danylo Khilko, Krzysztof Pietrzak, and Leonid Reyzin. Beyond Hellman’s time-memory trade-offs with applications to proofs of space. In Tsuyoshi Takagi and Thomas Peyrin, editors, _Advances in Cryptology - ASI- ACRYPT 2017 - 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part II_, volume 10625 of _Lecture Notes in Computer Science_, pages 357–379. Springer, 2017. | +| BBBF18 | Dan Boneh, Joseph Bonneau, Benedikt Bu ̈nz, and Ben Fisch. Verifiable delay functions. In Hovav Shacham and Alexandra Boldyreva, editors, _Advances in Cryptology - CRYPTO 2018 - 38th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 19-23, 2018, Proceedings, Part I, volume 10991 of Lecture Notes in Computer Science_, pages 757–788. Springer, 2018. | +| BBF18 | Dan Boneh, Benedikt Bu ̈nz, and Ben Fisch. A survey of two verifi- able delay functions. _IACR Cryptol. ePrint Arch._, page 712, 2018. | +| BDK+19 | Vivek Bagaria, Amir Dembo, Sreeram Kannan, Sewoong Oh, David Tse, Pramod Viswanath, Xuechao Wang, and Ofer Zeitouni. Proof- of-stake longest chain protocols: Security vs predictability. 2019. | +| BGK+18 | Christian Badertscher, Peter Gazi, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas. Ouroboros genesis: Composable proof-of-stake blockchains with dynamic availability. In David Lie, Mohammad Mannan, Michael Backes, and XiaoFeng Wang, editors, _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018_, pages 913–930. ACM, 2018. | +| BNPW19 | Jonah Brown-Cohen, Arvind Narayanan, Alexandros Psomas, and S. Matthew Weinberg. Formal barriers to longest-chain proof-of-stake protocols. In Anna Karlin, Nicole Immorlica, and Ramesh Johari, editors, _Proceedings of the 2019 ACM Conference on Economics and Computation, EC 2019, Phoenix, AZ, USA, June 24-28, 2019_, pages 459–473. ACM, 2019. | +| BP22 | Mirza Ahad Baig and Krzysztof Pietrzak. On the existence of proof of space longest chain protocols (working title), 2022. 2022. Manuscript in preparation. | +| CKWN16 | Miles Carlsten, Harry A. Kalodner, S. Matthew Weinberg, and Arvind Narayanan. On the instability of bitcoin without the block reward. In Edgar R. Weippl, Stefan Katzenbeisser, Christopher Kruegel, Andrew C. Myers, and Shai Halevi, editors, _Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016_, pages 154–167. ACM, 2016. | +| CP19 | Bram Cohen and Krzysztof Pietrzak. The chia network blockchain. 2019. | +| DFKP15 | Stefan Dziembowski, Sebastian Faust, Vladimir Kolmogorov, and Krzysztof Pietrzak. Proofs of space. In Rosario Gennaro and Matthew Robshaw, editors, _Advances in Cryptology - CRYPTO 2015 - 35th Annual Cryptology Conference, Santa Barbara, CA, USA, August 16-20, 2015, Proceedings, Part II, volume 9216 of Lecture Notes in Computer Science_, pages 585–605. Springer, 2015. | +| DKT21 | Soubhik Deb, Sreeram Kannan, and David Tse. Posat: Proof-of-work availability and unpredictability, without the work. In Nikita Borisov and Claudia Diaz, editors, _Financial Cryptography and Data Security - 25th International Conference, FC 2021, Virtual Event, March 1-5, 2021, Revised Selected Papers, Part II, volume 12675 of Lecture Notes in Computer Science_, pages 104–128. Springer, 2021. | +| DW13 | Christian Decker and Roger Wattenhofer. Information propagation in the bitcoin network. In _13th IEEE International Conference on Peer-to-Peer Computing, IEEE P2P 2013, Trento, Italy, September 9-11, 2013_, Proceedings, pages 1–10. IEEE, 2013. | +| EFKP20 | Naomi Ephraim, Cody Freitag, Ilan Komargodski, and Rafael Pass. Continuous verifiable delay functions. Naomi Ephraim, Cody Freitag, Ilan Komargodski, and Rafael Pass. Continuous verifiable delay functions. In Anne Canteaut and Yuval Ishai, editors, _Advances in Cryptology - EUROCRYPT 2020 - 39th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Zagreb, Croatia, May 10-14, 2020, Proceedings, Part III_, volume 12107 of _Lecture Notes in Computer Science_, pages 125–154. Springer, 2020. Springer, 2020. | +| ES18 | Ittay Eyal and Emin Gu ̈n Sirer. Majority is not enough: bitcoin mining is vulnerable. _Commun_. ACM, 61(7):95–102, 2018. | +| FZ17 | Lei Fan and Hong-Sheng Zhou. iching: A scalable proof-of-stake blockchain in the open setting (or, how to mimic nakamoto’s design via proof-of-stake). _IACR Cryptol. ePrint Arch._, page 656, 2017. | +| GKL15 | Juan A. Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol: Analysis and applications. In Elisabeth Oswald and Marc Fischlin, editors, _Advances in Cryptology - EUROCRYPT 2015 - 34th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Sofia, Bulgaria, April 26-30, 2015, Proceedings, Part II_, volume 9057 of _Lecture Notes in Computer Science_, pages 281–310. Springer, 2015. | +| GKR18 | Peter Gazi, Aggelos Kiayias, and Alexander Russell. Stake-bleeding attacks on proof-of-stake blockchains. In _Crypto Valley Conference on Blockchain Technology, CVCBT 2018, Zug, Switzerland, June 20-22, 2018_, pages 85–92. IEEE, 2018. | +| Hel80 | Martin E. Hellman. A cryptanalytic time-memory trade-off. _IEEE Trans. Inf. Theory_, 26(4):401–406, 1980. | +| Lew21 | Andrew Lewis-Pye. Byzantine generals in the permissionless setting. _CoRR_, abs/2101.07095, 2021. | +| LR21 | Andrew Lewis-Pye and Tim Roughgarden. How does blockchain security dictate blockchain implementation? In Yongdae Kim, Jong Kim, Giovanni Vigna, and Elaine Shi, editors, _CCS ’21: 2021 ACM SIGSAC Conference on Computer and Communications Security, Virtual Event, Republic of Korea, November 15 - 19, 2021_, pages 1006–1019. ACM, 2021. | +| Pie19a | Krzysztof Pietrzak. Proofs of catalytic space. In Avrim Blum, editor, _10th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 10-12, 2019, San Diego, California, USA_, volume 124 of LIPIcs, pages 59:1–59:25. Schloss Dagstuhl - Leibniz- Zentrum für Informatik, 2019. | +| Pie19b | Krzysztof Pietrzak. Simple verifiable delay functions. In Avrim Blum, editor, 1*0th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 10-12, 2019, San Diego, California, USA*, volume 124 of LIPIcs, pages 60:1–60:15. Schloss Dagstuhl - Leibniz-Zentrum fu ̈r Informatik, 2019. | +| PKF+18 | Sunoo Park, Albert Kwon, Georg Fuchsbauer, Peter Gazi, Joël Alwen, and Krzysztof Pietrzak. Spacemint: A cryptocurrency based on proofs of space. In Sarah Meiklejohn and Kazue Sako, editors, _Financial Cryptography and Data Security - 22nd International Conference, FC 2018, Nieuwpoort, Cura ̧cao, February 26 - March 2, 2018, Revised Selected Papers_, volume 10957 of _Lecture Notes in Computer Science_, pages 480–499. Springer, 2018. | +| PS17 | Rafael Pass and Elaine Shi. The sleepy model of consensus. Rafael Pass and Elaine Shi. The sleepy model of consensus. In Tsuyoshi Takagi and Thomas Peyrin, editors, _Advances in Cryptology - ASIACRYPT 2017 - 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part II_, volume 10625 of _Lecture Notes in Computer Science_, pages 380–409. Springer, 2017. Springer, 2017. | +| SNM+21 | Caspar Schwarz-Schilling, Joachim Neu, Barnab ́e Monnot, Aditya Asgaonkar, Ertem Nusret Tas, and David Tse. Three attacks on proof-of-stake ethereum. _IACR Cryptol. ePrint Arch._, page 1413, 2021. | +| SSZ15 | Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar. Optimal selfish mining strategies in bitcoin. _CoRR_, abs/1507.06183, 2015. | +| Wes20 | Benjamin Wesolowski. Efficient verifiable delay functions. _J. Cryptol._, 33(4):2113–2147, 2020. | ## Additional Reading diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/hash-and-vdf-chains.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/hash-and-vdf-chains.md index 8f6a61aeb8..a700077553 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/hash-and-vdf-chains.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/hash-and-vdf-chains.md @@ -29,8 +29,8 @@ A hash chain is immutable in the following sense: ## 4.2 VDF chains
- Illustration of a VDF chain -
Figure 6: Illustration of a VDF chain.
+ Illustration of a VDF chain +
Figure 6: Illustration of a VDF chain.
A VDF chain is a sequence @@ -72,7 +72,9 @@ VDF chains give two basic security guarantees, the first is immutability analogo **Proposition 3** (immutability and sequentiality of VDF chains). *Like a hash chain, a VDF chain is *immutable* in the sense that it's computationally infeasible to come up with two different VDF chains* $$ -{\cal V}=z_0,\tau_1,z_1,\tau_2,z_2,\ldots,\tau_\ell \qquad {\cal V}'=z'_0,\tau'_1,z'_1,\tau'_2,z'_2,\ldots,\tau'_{\ell'} +{\cal V}=z_0,\tau_1,z_1,\tau_2,z_2,\ldots,\tau_\ell +\qquad +{\cal V}'=z'_0,\tau'_1,z'_1,\tau'_2,z'_2,\ldots,\tau'_{\ell'} $$ where the last VDF outputs collide, i.e., $\tau_\ell.{\sf y}=\tau'_{\ell'}.{\sf y}$. Here different means that either they have different length $\ell\neq \ell'$ and neither is a prefix of the other. Or (if $\ell=\ell'$) there exists an $i$ s.t. either $z_i\neq z'_i$ or $\tau_i.{\sf y}\neq \tau'_i.{\sf y}$ or $\tau.{\sf t}\neq \tau'.{\sf t}$. Note that we ignore the proofs $\tau.\pi$ when comparing chains (we just use them to determine whether the chain is valid) as they must not be unique. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/longest-chain-protocols.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/longest-chain-protocols.md index dc5744e42d..594a54c6dd 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/longest-chain-protocols.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/longest-chain-protocols.md @@ -8,7 +8,7 @@ slug: /longest-chain-protocols Before we can outline the specification of the $\textrm{{\sf Chia}}$ blockchain and its rationale in more detail, we first must understand the general challenges one faces when constructing a PoSpace based blockchain and some of the relevant literature on how to address these challenges. -Ultimately, we want to argue security assuming only that sufficient fraction of the resource (space, fast VDFs) is controlled by _rational_ parties. Towards this, in this Section we first discuss how to achieve security assuming sufficiently many parties are _honest_, and then in §3 how _rational_ behavior is incentivized by ensuring that deviating from the protocol will not give any (or very little) extra reward to parties. +Ultimately, we want to argue security assuming only that sufficient fraction of the resource (space, fast VDFs) is controlled by _rational_ parties. Towards this, in this Section we first discuss how to achieve security assuming sufficiently many parties are _honest_, and then in §3 how _rational_ behavior is incentivized by ensuring that deviating from the protocol will not give any (or very little) extra reward to parties. Towards this, in this Section we first discuss how to achieve security assuming sufficiently many parties are _honest_, and then in §3 how _rational_ behavior is incentivized by ensuring that deviating from the protocol will not give any (or very little) extra reward to parties.
alt text @@ -21,7 +21,7 @@ As mentioned in the introduction, just replacing proofs of work in Bitcoin with In longest-chain blockchains the challenge used to determine the miner/farmer who can add a block is derived from the chain itself. In Bitcoin, where the challenge for a block is simply the hash of the previous block, a miner can influence the PoW challenge by trying out different transaction sets or time stamps. While such "grinding" through different challenges gives no advantage in PoW based cryptocurrencies, it's a problem once we use an efficient proof system. -To prevent such grinding we adopt an approach from Spacemint [PKF+18] and _split the chain_ in two parts which we'll call trunk and foliage. The trunk contains only canonical proofs, and the challenges depend only on values contained in the trunk. This way the only choice a farmer has to influence the challenge is by withholding a winning block. The foliage contains all the remaining "grindeable" content, in particular transactions and time-stamps. +To prevent such grinding we adopt an approach from Spacemint [PKF+18] and _split the chain_ in two parts which we'll call trunk and foliage. The trunk contains only canonical proofs, and the challenges depend only on values contained in the trunk. This way the only choice a farmer has to influence the challenge is by withholding a winning block. The foliage contains all the remaining "grindeable" content, in particular transactions and time-stamps. The trunk contains only canonical proofs, and the challenges depend only on values contained in the trunk. This way the only choice a farmer has to influence the challenge is by withholding a winning block. The foliage contains all the remaining "grindeable" content, in particular transactions and time-stamps. ## 2.2 Double-Dipping @@ -29,7 +29,7 @@ Even once grinding is no longer an option, an adversary can in private create an To limit the impact of double-dipping an early version [CP19] of $\textrm{{\sf Chia}}$ consensus specified that also the honest parties do a very limited form of double-dipping and try to extend the best $3$ blocks they see at every depth, this rule was (by simulations) shown to increase the space required by an adversary from the $26.9\%$ mentioned above, to $38.5\%$. -The deployed $\textrm{{\sf Chia}}$ protocol uses _correlated randomness_ to limit the impact of double dipping. This elegant idea was introduced in [BDK+19], and basically suggest to only use every $k$th block to compute the challenges.[^1] The authors of [BDK+19] determine the exact fraction of the _resource_ the adversary must control to break security as a function of $k$ (as mentioned, it's $2.718$ for $k=1$, and goes to $1$ as $k$ increases). $\textrm{{\sf Chia}}$ uses a variant where a challenge depends on one out of _at least_ (not exactly) $k=16$ blocks. Their analysis also applies to this setting, and with $k=16$ states that by double dipping the adversary can boost their resource by a factor of $1.47$, which means they must control at least a $\frac{1}{1+1.47}=0.405$ fraction of the resource for an attack. +The deployed $\textrm{{\sf Chia}}$ protocol uses _correlated randomness_ to limit the impact of double dipping. The deployed $\textrm{{\sf Chia}}$ protocol uses _correlated randomness_ to limit the impact of double dipping. This elegant idea was introduced in [BDK+19], and basically suggest to only use every $k$th block to compute the challenges.[^1] The authors of [BDK+19] determine the exact fraction of the _resource_ the adversary must control to break security as a function of $k$ (as mentioned, it's $2.718$ for $k=1$, and goes to $1$ as $k$ increases). $\textrm{{\sf Chia}}$ uses a variant where a challenge depends on one out of _at least_ (not exactly) $k=16$ blocks. Their analysis also applies to this setting, and with $k=16$ states that by double dipping the adversary can boost their resource by a factor of $1.47$, which means they must control at least a $\frac{1}{1+1.47}=0.405$ fraction of the resource for an attack. $\textrm{{\sf Chia}}$ uses a variant where a challenge depends on one out of _at least_ (not exactly) $k=16$ blocks. Their analysis also applies to this setting, and with $k=16$ states that by double dipping the adversary can boost their resource by a factor of $1.47$, which means they must control at least a $\frac{1}{1+1.47}=0.405$ fraction of the resource for an attack. The resource considered in [BDK+19] is simply stake, while in $\textrm{{\sf Chia}}$ it's the product of space and VDF speed. Concerning VDFs, while for the honest parties the only thing that matters is the _speed_ of the three VDFs controlled by the fastest honest time lord, for an adversary the speed as well as the number of VDFs available to them matter. In the security analysis we can simply assume the adversary controls an unbounded number of VDFs, as that's when the analysis from [BDK+19] applies. This is how eq.(2) $space_h\cdot vdf_h > space_a \cdot vdf_a \cdot 1.47$ in §1.1 was derived. @@ -44,6 +44,6 @@ A major issue with longest-chain blockchains based on efficient proof systems i Existing proposals to achieve security under such _dynamic availability_ include check-pointing, which is problematic as parties that join for the first time or have not followed the chain for a longer period need additional trust assumptions to decide which chain to follow. Unlike for grinding and double-dipping, the attacks that become possible due to bootstrapping are quite different for proofs of space and proofs of stake. In the latter one must consider old keys that hold no stake in the current chain, but still can be used to bootstrap from a past block. To address this it was suggested to have honest parties use key-evolution schemes [BGK+18] so the current keys cannot be used to create blocks in the past. Key-evolution is problematic as it's clearly not rational for honest parties to do; they could sell their keys or lose their stake in case of a deep reorg. -The essence of the bootstrapping problem is the fact that one cannot ensure that time has passed in-between the creation of subsequent blocks. $\textrm{{\sf Chia}}$ solves this problem by combining proofs of space with _proofs of time_, concretely, verifiable delay functions (VDFs), which enforce that some inherently sequential computation (which requires time linear in the length of the computation) was performed in-between the creation of blocks. $\textrm{{\sf Chia}}$ combines those three countermeasures (splitting the chain, correlated randomness and proofs of time) into a single design which is secure if the resources controlled by the honest parties satisfy the bound from Eq. +The essence of the bootstrapping problem is the fact that one cannot ensure that time has passed in-between the creation of subsequent blocks. The essence of the bootstrapping problem is the fact that one cannot ensure that time has passed in-between the creation of subsequent blocks. $\textrm{{\sf Chia}}$ solves this problem by combining proofs of space with _proofs of time_, concretely, verifiable delay functions (VDFs), which enforce that some inherently sequential computation (which requires time linear in the length of the computation) was performed in-between the creation of blocks. $\textrm{{\sf Chia}}$ combines those three countermeasures (splitting the chain, correlated randomness and proofs of time) into a single design which is secure if the resources controlled by the honest parties satisfy the bound from Eq. $\textrm{{\sf Chia}}$ combines those three countermeasures (splitting the chain, correlated randomness and proofs of time) into a single design which is secure if the resources controlled by the honest parties satisfy the bound from Eq. [^1]: Using the same challenge for $k>1$ blocks has already been suggested in [PKF+18], but this is a different requirement (as the challenge can still depend on all blocks) and adds much less security than correlated randomness for small $k$. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/rational-attackers.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/rational-attackers.md index 551137c968..73861a7799 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/rational-attackers.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/rational-attackers.md @@ -8,9 +8,9 @@ slug: /rational-attackers In §2 we discussed how costless simulation opens attack vectors for double spending in longest-chain blockchains and how these are addressed in $\textrm{{\sf Chia}}$. To show security we assumed that a sufficient fraction of the resource is controlled by _honest_ parties who follow the protocol rules. In reality it's unrealistic to assume that parties will behave altruistically, instead we need to argue that it's _rational_ for parties to follow the protocol rules. Unfortunately costless simulation also makes this task much more challenging than in a PoW based system. -In analogy to _selfish mining_ in Bitcoin, we refer to strategies by which a party gets more rewards than they would by following the protocol rules as _selfish farming_. To argue that rational parties will behave honestly it's necessary to bound the efficacy of selfish mining/farming strategies. +In analogy to _selfish mining_ in Bitcoin, we refer to strategies by which a party gets more rewards than they would by following the protocol rules as _selfish farming_. To argue that rational parties will behave honestly it's necessary to bound the efficacy of selfish mining/farming strategies. To argue that rational parties will behave honestly it's necessary to bound the efficacy of selfish mining/farming strategies. -In §3.1 below we first discuss selfish mining and why we don't observe it in Bitcoin even though it's possible in principle. As directly analyzing the security of a longest-chain protocol against selfish mining/farming is very challenging we take a modular approach. In §3.2 we first identify two properties – _no slowdown_ and _delayed gratification_ illustrated in Figure 5 – which are satisfied by Bitcoin, and then show in §3.3 that they imply robustness against selfish mining (through the notion of chain quality) of the level as achieved by Bitcoin. In §3.4 and §3.5 we then sketch how those notions are achieved in $\textrm{{\sf Chia}}$. +In §3.1 below we first discuss selfish mining and why we don't observe it in Bitcoin even though it's possible in principle. As directly analyzing the security of a longest-chain protocol against selfish mining/farming is very challenging we take a modular approach. In §3.1 below we first discuss selfish mining and why we don't observe it in Bitcoin even though it's possible in principle. As directly analyzing the security of a longest-chain protocol against selfish mining/farming is very challenging we take a modular approach. In §3.2 we first identify two properties – _no slowdown_ and _delayed gratification_ illustrated in Figure 5 – which are satisfied by Bitcoin, and then show in §3.3 that they imply robustness against selfish mining (through the notion of chain quality) of the level as achieved by Bitcoin. In §3.4 and §3.5 we then sketch how those notions are achieved in $\textrm{{\sf Chia}}$. In §3.4 and §3.5 we then sketch how those notions are achieved in $\textrm{{\sf Chia}}$. ## 3.1 Selfish Mining in Bitcoin @@ -26,24 +26,26 @@ While Bitcoin prevents double spending assuming a majority of the hashing power The Bitcoin blockchain is split in epochs, each with a targeted duration of two weeks, and only at the end of an epoch the difficulty is reset to accommodate for the variation of the hashing power. Assuming the network is reliable, within an epoch, a selfish miner cannot create more blocks than they would get by honest mining. This follows from a crucial property of proofs of work: there's no way to find more proofs of a given difficulty (and thus blocks) in a given time window than simply following the protocol and always working on the known longest chain. The only thing selfish mining does in Bitcoin is to make honest parties waste their hashing power, so after the next difficulty reset (which only happens every 2 weeks) the difficulty is lower than it should be, and only at this point the selfish miner makes some extra profit. Another property of PoW based chains like Bitcoin is that an adversary cannot slow down chain growth. We capture these two desirable properties separately below. -**Delayed Gratification:** A chain where an adversary cannot increase the number of blocks they find in expectation within an epoch of same difficulty by deviating from the honest strategy is said to have the _delayed gratification_ property. In $\textrm{{\sf Chia}}$, by "not deviating" we mean that the adversary simply runs an honest farmer using its available space, and additionally, should the adversary control VDFs that are faster than the fastest honest time lord, they are also assumed to run a time lord. Intuitively, delayed gratification is a good deterrent to selfish mining by itself as it limits selfish mining to adversaries who follow a "long term" agenda. +**Delayed Gratification:** A chain where an adversary cannot increase the number of blocks they find in expectation within an epoch of same difficulty by deviating from the honest strategy is said to have the _delayed gratification_ property. In $\textrm{{\sf Chia}}$, by "not deviating" we mean that the adversary simply runs an honest farmer using its available space, and additionally, should the adversary control VDFs that are faster than the fastest honest time lord, they are also assumed to run a time lord. Intuitively, delayed gratification is a good deterrent to selfish mining by itself as it limits selfish mining to adversaries who follow a "long term" agenda. In $\textrm{{\sf Chia}}$, by "not deviating" we mean that the adversary simply runs an honest farmer using its available space, and additionally, should the adversary control VDFs that are faster than the fastest honest time lord, they are also assumed to run a time lord. Intuitively, delayed gratification is a good deterrent to selfish mining by itself as it limits selfish mining to adversaries who follow a "long term" agenda. **No Slowdown:** A chain where an adversary (no matter what fraction of the resource they control) cannot slow down the expected block arrival time by interacting with the chain is said to have the _no slowdown_ property. ## 3.3 Chain Quality -A longest-chain blockchain is said to have _chain quality_ $\rho$ if the fraction of blocks mined by honest miners is at least $\rho$ (with high probability and considering a sufficiently large number of blocks). Chain quality was introduced in [GKL15] as a metric to quantify how susceptible a chain is to selfish mining. Ideally, assuming an adversarial miner who controls an $\alpha$ fraction of the resource, the chain quality should be $\rho=1-\alpha$ as this means that the adversary cannot increase its fraction of blocks by deviating. +A longest-chain blockchain is said to have _chain quality_ $\rho$ if the fraction of blocks mined by honest miners is at least $\rho$ (with high probability and considering a sufficiently large number of blocks). Chain quality was introduced in [GKL15] as a metric to quantify how susceptible a chain is to selfish mining. Ideally, assuming an adversarial miner who controls an $\alpha$ fraction of the resource, the chain quality should be $\rho=1-\alpha$ as this means that the adversary cannot increase its fraction of blocks by deviating. Chain quality was introduced in [GKL15] as a metric to quantify how susceptible a chain is to selfish mining. Ideally, assuming an adversarial miner who controls an $\alpha$ fraction of the resource, the chain quality should be $\rho=1-\alpha$ as this means that the adversary cannot increase its fraction of blocks by deviating. By the Proposition below delayed gratification and the no slowdown property imply a bound on _chain quality_ which matches the bound proven for Bitcoin (when ignoring network delays). --- -**Proposition 1** (Delayed Gratification and No Slowdown implies Chain Quality). _Consider a longest-chain protocol which has the delayed gratification and no slowdown property against an adversary who controls an $\alpha$ fraction of the global resource, then the chain quality is $1-\frac{\alpha}{1-\alpha}$ (compared to the ideal $1-\alpha$)._ +**Proposition 1** (Delayed Gratification and No Slowdown implies Chain Quality). **Proposition 1** (Delayed Gratification and No Slowdown implies Chain Quality). _Consider a longest-chain protocol which has the delayed gratification and no slowdown property against an adversary who controls an $\alpha$ fraction of the global resource, then the chain quality is $1-\frac{\alpha}{1-\alpha}$ (compared to the ideal $1-\alpha$)._ -_Proof._ Consider an adversarial miner ${\cal A}$ with an $\alpha$ fraction of the resource and let $\ell$ denote the (expected) number of blocks to be found if everyone would mine honestly. By the no slowdown property, no matter what ${\cal A}$ does the number of blocks found is at least $\ell'\ge (1-\alpha)\cdot\ell$. By delayed gratification, at most $\alpha\cdot\ell$ of those blocks were created by ${\cal A}$, we get a chain quality of +_Proof._ Consider an adversarial miner ${\cal A}$ with an $\alpha$ fraction of the resource and let $\ell$ denote the (expected) number of blocks to be found if everyone would mine honestly. By the no slowdown property, no matter what ${\cal A}$ does the number of blocks found is at least $\ell'\ge (1-\alpha)\cdot\ell$. By delayed gratification, at most $\alpha\cdot\ell$ of those blocks were created by ${\cal A}$, we get a chain quality of By the no slowdown property, no matter what ${\cal A}$ does the number of blocks found is at least $\ell'\ge (1-\alpha)\cdot\ell$. By delayed gratification, at most $\alpha\cdot\ell$ of those blocks were created by ${\cal A}$, we get a chain quality of $$ -\begin{aligned} \textit{chain quality}&=\frac{\text{honest blocks}}{\text{total blocks}}\\ &=\frac{\ell' - \alpha \cdot \ell}{\ell'}\\ &=1-\frac{\alpha\cdot\ell}{\ell'}\\ &\ge 1-\frac{\alpha\cdot\ell}{(1-\alpha)\cdot \ell}\\ &=1-\frac{\alpha}{1-\alpha} \hspace{10em}\square \end{aligned} +\begin{aligned} \textit{chain quality}&=\frac{\text{honest blocks}}{\text{total blocks}}\\ +&=\frac{\ell' - \alpha \cdot \ell}{\ell'}\\ &=1-\frac{\alpha\cdot\ell}{\ell'}\\ +&\ge 1-\frac{\alpha\cdot\ell}{(1-\alpha)\cdot \ell}\\ &=1-\frac{\alpha}{1-\alpha} \hspace{10em}\square \end{aligned} $$ --- @@ -113,7 +115,7 @@ For example the difference in the $g$-greedy and the $D$-distance greedy protoco Unlike the chain specification, which can only be changed by a hard fork once the chain is deployed, the chain selection rule can easily be adapted by the farmers and/or time lords even after the launch. Finding a chain-selection rule for the $\textsf{Chia}$ chain which provably achieves no-slowdown is an interesting open problem. -Under the additional assumption that an adversary does not control VDFs which are _faster_ than the fastest honest time lord, a very simple chain selection rule achieving no-slowdown exists: always follow the chain with accumulated most VDF steps. Of course this rule would be terrible in practice as security completely breaks if the adversary has an even slightly faster VDF than the fastest honest time lord. For example, such an adversary could create an "empty" chain by refusing to infuse any blocks. +Under the additional assumption that an adversary does not control VDFs which are _faster_ than the fastest honest time lord, a very simple chain selection rule achieving no-slowdown exists: always follow the chain with accumulated most VDF steps. Of course this rule would be terrible in practice as security completely breaks if the adversary has an even slightly faster VDF than the fastest honest time lord. For example, such an adversary could create an "empty" chain by refusing to infuse any blocks. Of course this rule would be terrible in practice as security completely breaks if the adversary has an even slightly faster VDF than the fastest honest time lord. For example, such an adversary could create an "empty" chain by refusing to infuse any blocks. A more sensible rule is to simply follow the _heaviest_ fork like in Bitcoin. Unfortunately, unlike in Bitcoin, in $\textsf{Chia}$ the heaviest fork is not necessarily the fork which will be heaviest in the future assuming all honest parties adapt it: a fork $A$ might have one more block infused than some fork $B$, but if $B$ is way ahead in the VDF computation extending $B$ might give a better chain (in expectation) in the future. Thus, when using this rule, by releasing $B$ an adversary might slow down the chain. The currently deployed chain selection rule for farmers and time lords is basically to follow the heaviest fork, but with some heuristics to avoid clear cases where switching to a heavier chain is slowing down growth. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/recovering-from-51-percent-attacks.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/recovering-from-51-percent-attacks.md index c80a4ab305..42ab5f8a46 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/recovering-from-51-percent-attacks.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/recovering-from-51-percent-attacks.md @@ -10,11 +10,15 @@ In this Section we have a look at two closely related security properties of lon We discussed in §2 the main security issues of a PoSpace based longest-chain blockchain arise from the fact that PoSpace is an efficient proof system. PoSpace shares those security challenges with PoStake, and all three countermeasures summarized in Figure 3 (namely splitting the chain to prevent grinding, correlated randomness to prevent double-dipping and using VDFs to prevent bootstrapping) can readily be applied in the stake setting, correlated randomness was even originally proposed for stake [BDK+19]. But as we'll discuss below, when it comes to security under dynamic availability or 51% attacks there are fundamental differences between space and stake. In particular, using proofs of space in combination with VDFs one can handle both attacks basically as well as with proofs of work, while proofs of stake cannot, even in combination with VDFs. +{' '} +
- ![](/img/green-paper/table-1.png) +
- Table 1: Summary of the ability to heal from malicious majority and provide security under dynamic availability of longest-chain protocols based various proof systems. -
+ Table 1: Summary of the ability to heal from malicious majority and provide + security under dynamic availability of longest-chain protocols based various + proof systems. +
## 6.1 Recovery from $51\%$ Attacks @@ -30,7 +34,9 @@ While Bitcoin provides no security if more than half of the hashrate is controll A bit more formally, let ${\sf PoW}_h(t)$ and ${\sf PoW}_a(t)$ denote the hashing power of the honest and adversarial parties at clock time $t$, respectively. For $t_0eq.(11)
+
eq.(11)
If this holds the adversary can simply start at time $t_0$ to mine a chain in private, and release it at time $t_1$. By the first inequality the adversaries chain will be heavier than the honest one with probability at least $0.5$, and by the 2nd the honest block added at time $t$ will be buried by $k$ blocks with probability $0.5$, so both hold and we have a successful double spending attack with probability at least $\approx 0.5^2=0.25$ (it can actually be a bit less than that as the two events are negatively correlated). To be secure it's not sufficient that no $t_0,t_1$ as in eq.(11) exist, but one needs to be "sufficiently far" from this situation to guarantee that double spending can only happen with some tiny probability. From the standard Chernoff bound it follows that the probability that a fork starting at a block added at time $t_0$ and being released at time $t_1$ will be successful (i.e., have higher weight than the honest chain) is exponentially small in the number of expected honest blocks ${\sf PoW}_h(t_0,t_1)/D$ and the square of the honest to adversarial advantage, i.e., $$ -\begin{aligned} &\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ &\le -\exp\left(\frac{\mathsf{PoW}_h(t_0,t_1)}{D} \cdot\left( \frac{\mathsf{PoW}_h(t_0,t_1)}{\mathsf{PoW}_a(t_0,t_1)}-1 \right)^2\right) \end{aligned} +\begin{aligned} +&\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ +&\le -\exp\left(\frac{\mathsf{PoW}_h(t_0,t_1)}{D} \cdot\left( \frac{\mathsf{PoW}_h(t_0,t_1)}{\mathsf{PoW}_a(t_0,t_1)}-1 \right)^2\right) +\end{aligned} $$ -
eq.(12)
+
eq.(12)
### 6.1.2 Recovering from PoStake Majority @@ -78,22 +87,28 @@ $vdf_h$ only considers the fastest honest time lord, as only they matter for the Define the honest and adversarial resource at time time as the product of their space and VDF speed $$ -{\sf PoST}_h(t)=space_h(t)\cdot vdf_h(t)\quad,\quad {\sf PoST}_a(t)=space_a(t)\cdot vdf_a(t) +{\sf PoST}_h(t)=space_h(t)\cdot vdf_h(t)\quad,\quad +{\sf PoST}_a(t)=space_a(t)\cdot vdf_a(t) $$ and analogously to the work setting let the cumulative space-time resource in a window from $t_0$ to $t_1$ be $$ -{\sf PoST}_h(t_0,t_1)= \int_{t_0}^{t_1}{\sf PoST}_h(t) \,dt \quad , \quad {\sf PoST}_a(t_0,t_1)= \int_{t_0}^{t_1} {\sf PoST}_a(t) \,dt +{\sf PoST}_h(t_0,t_1)= \int_{t_0}^{t_1}{\sf PoST}_h(t) \,dt +\quad , \quad +{\sf PoST}_a(t_0,t_1)= \int_{t_0}^{t_1} {\sf PoST}_a(t) \,dt $$ With these definitions we now get a similar bound on the probability that an adversary can create a fork starting at $t_0$ and being released at time $t_1$ as we did for PoW in eq.(12) $$ -\begin{aligned} &\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ &\le -\exp\left(\frac{\mathsf{PoST}_h(t_0,t_1)}{D} \cdot\left( \frac{\mathsf{PoST}_h(t_0,t_1)}{1.47\cdot \mathsf{PoST}_a(t_0,t_1)}-1 \right)^2\right) \end{aligned} +\begin{aligned} +&\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ +&\le -\exp\left(\frac{\mathsf{PoST}_h(t_0,t_1)}{D} \cdot\left( \frac{\mathsf{PoST}_h(t_0,t_1)}{1.47\cdot \mathsf{PoST}_a(t_0,t_1)}-1 \right)^2\right) +\end{aligned} $$ -
eq.(13)
+
eq.(13)
A difference to the PoW setting is the additional $1.47$ factor boosting the adversary's resource which is necessary to account for the fact that they can do some bounded double dipping. @@ -111,15 +126,18 @@ $$ {\sf PoW}_a(t)\le f\cdot {\sf PoW}_h(t) $$ -
eq.(14)
+
eq.(14)
To see that Bitcoin is secure under dynamic availability we can reuse our inequality eq.(12) which using $\frac{{\sf PoW}_h(t_0,t_1)}{{\sf PoW}_a(t_0,t_1)}\ge f$ simplifies to (recall that $\frac{{\sf PoW}_h(t_0,t_1)}{D}$ is the expected number of honest blocks in the $t_0$ to $t_1$ window) $$ -\begin{aligned} &\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ &\le -\exp\left(\frac{\mathsf{PoW}_h(t_0,t_1)}{D} \cdot\left(f-1 \right)^2\right) \end{aligned} +\begin{aligned} +&\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ +&\le -\exp\left(\frac{\mathsf{PoW}_h(t_0,t_1)}{D} \cdot\left(f-1 \right)^2\right) +\end{aligned} $$ -
eq.(15)
+
eq.(15)
Which simply means that the probability that an adversary will be able to create any particular a fork decreases exponentially in the length of the fork. @@ -131,15 +149,18 @@ $$ {\sf PoST}_a(t)\le f\cdot {\sf PoST}_h(t) $$ -
eq.(16)
+
eq.(16)
With this eq.(13) becomes $$ -\begin{aligned} &\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ &\le -\exp\left(\frac{\mathsf{PoST}_h(t_0,t_1)}{D} \cdot\left( \frac{f}{1.47}-1 \right)^2\right) \end{aligned} +\begin{aligned} +&\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ +&\le -\exp\left(\frac{\mathsf{PoST}_h(t_0,t_1)}{D} \cdot\left( \frac{f}{1.47}-1 \right)^2\right) +\end{aligned} $$ -
eq.(17)
+
eq.(17)
Thus like in Bitcoin, in $\textsf{Chia}$ the probability of a successful fork decreases exponentially fast in the length of the fork. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/the-chia-blockchain.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/the-chia-blockchain.md index 908e7b6e5e..b5f06b72a0 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/the-chia-blockchain.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/green-paper/the-chia-blockchain.md @@ -19,7 +19,7 @@ In this section we finally outline the design of the $\textsf{Chia}$ blockchain ### 5.1.1 Variables -| 变量 | Definition | +| Variable | Definition | | ---------------- | -------------------------------------------------------------------------------------------------------------------------- | | $T_i$ | Time parameter of $i$-th slot (# of VDF steps per sub-slot). Recalibrated once per day for 10 minutes per sub-slot target. | | $\mathsf{spi}_i$ | $$\mathsf{spi}_i \stackrel{\text{\tiny def}}{=} \frac{T_i}{64}$$ | @@ -90,7 +90,8 @@ $$ Here $\tau^{\cal CC}_i$ is the VDF computation for the $i$th slot. Usually its number of VDF steps is the current time parameter $T_i$ (and should take 10 minutes to compute), but in exceptional cases it can be an integer multiple $\kappa_i\in\mathbb{N}$ of that as we enforce a 16 block minimum per slot $$ -\tau^{\cal CC}_i.{\sf t} = \kappa_i\cdot T_i \qquad\textrm{typically $\kappa_i=1$} +\tau^{\cal CC}_i.{\sf t} = \kappa_i\cdot T_i +\qquad\textrm{typically $\kappa_i=1$} $$ The value ${\sf ic}_i$ infused at the beginning of slot $i+1$ depends on the first block in slot $i$, we'll explain how exactly in §5.5. @@ -116,7 +117,8 @@ The reward chain ${\cal RC}$ is a VDF chain that the time lords evaluate in para Whenever a farmer receives new signage points ${\sf cc\_sp}_{i,j},{\sf rc\_sp}_{i,j}$ they first check whether this points lie on a heaviest chain (cf. the discussion in §1.5) and their VDF proofs verify. If the this is the case, the farmer checks they can create a winning PoSpace proof. This process will, for a subset of the plots, produce a PoSpace $\sigma$ and some additional value $\sigma.{\sf required\_iterations}$. Whether this PoSpace is a winning proof is now determined by the time parameter $T_i$ as $$ -\textrm{winning condition : } \sigma.{\sf required\_iterations} < {\sf spi}_i\quad (=T_i/64) +\textrm{winning condition : } +\sigma.{\sf required\_iterations} < {\sf spi}_i\quad (=T_i/64) $$
eq.(7)
@@ -194,7 +196,8 @@ $$ now the challenge $x$ is derived from the PoSpace in this block and the value of ${\cal CC}$ at the depth of its infusion point $$ -\quad x\gets {\sf VDF.sample}(\sigma,{\cal CC}[{\sf rc\_ip}(\beta_T).{\sf D}].{\sf y}) +\quad +x\gets {\sf VDF.sample}(\sigma,{\cal CC}[{\sf rc\_ip}(\beta_T).{\sf D}].{\sf y}) $$ the number of steps $t$ is the the remaining number of VDF steps in the slot, so the value ${\sf ic}_i$ will be available at the end of the slot when it's required, but not earlier diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat-creation-tutorial.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat-creation-tutorial.md index 10efda30b0..922883a9b3 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat-creation-tutorial.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat-creation-tutorial.md @@ -1,5 +1,5 @@ --- -slug: "/guides/cat-creation-tutorial" +slug: /guides/cat-creation-tutorial title: CAT Creation Tutorial --- @@ -30,7 +30,7 @@ For any questions regarding this tutorial, head over to the #chialisp channel on CAT denominations, as well as the rules behind issuance and melting, can take some getting used to. Here are a few things to keep in mind before you issue your CAT: - Most Chia wallets choose to display their value in XCH. However, this is a purely cosmetic choice because Chia's blockchain only knows about mojos. One XCH is equal to one trillion (1,000,000,000,000) mojos. -- In a similar vein, Chia Network, Inc. has made the design decision to map 1 CAT to 1000 mojos. This ratio will be the same for all CATs. +- In a similar vein, Chia Network Inc. has made the design decision to map 1 CAT to 1000 mojos. This ratio will be the same for all CATs. :::caution Theoretically, it would be possible to set the CAT:mojo ratio to something other than 1:1000 for a specific CAT, but we strongly recommend against doing this. The Chia reference wallet will not support CATs with a ratio other than 1:1000. Additionally, if you created your own wallet with support for different ratios, users of this wallet would almost certainly be confused and accidentally spend too much or too little money, by multiple orders of magnitude. Please don't attempt this. @@ -49,7 +49,7 @@ These concepts are discussed in greater detail in our [CAT primitive page](https Cat issuance comes in two phases. First, you will test your issuance on a testnet. Once ready, you will issue on mainnet. -For this tutorial, we'll use testnet10. +For this tutorial, we'll use testnet11. Ensure that you have Python 3.7 or later by running: @@ -58,7 +58,7 @@ Ensure that you have Python 3.7 or later by running: 1. Install the latest version of Chia's reference wallet. For more info, see our [installation guide](/installation). -2. Configure Chia to run on testnet10. For more info, see our [testnet documentation](/guides/crash-course/introduction#getting-on-testnet). +2. Configure Chia to run on testnet11. For more info, see our [testnet documentation](/guides/crash-course/introduction#getting-on-testnet). 3. Start Chia's reference wallet GUI. The command you use will depend on your OS, as well as whether you used a binary installer or installed from source. If you need help, see the installation guide. @@ -72,14 +72,13 @@ You can also run Chia's reference wallet from a [command line](/installation#cli 4. Add a new wallet if you have not already done so. -5. You will need to have a sufficient number of mojos for your CAT issuance and transaction fee(s). You can request some TXCH from the [Testnet10 faucet](https://testnet10-faucet.chia.net). +5. You will need to have a sufficient number of mojos for your CAT issuance and transaction fee(s). You can request some TXCH from the [Testnet11 faucet](https://testnet11-faucet.chia.net). 6. Before issuing a CAT, you will need to have a synced wallet, as demonstrated by the green checkmark inside the red circle in this image:
Synced wallet
-
Once you have a synced wallet and some TXCH, you are ready to run the CAT admin tool. @@ -208,7 +207,7 @@ You might receive an error such as ERROR: Failed building wheel for CAT-admin-to ---
- + Your environment should be all set, but let's make sure: - Run `cats --help`. You should get a usage statement. @@ -340,7 +339,6 @@ Now you can add a wallet ID for your new CAT. In the lower left corner, click `M
Manage Token List
-
The first few tokens listed will be there by default (Marmot, Spacebucks, etc). At the end of the list, you should find your CAT's `asset ID`. Feel free to rename your CAT, and click the slider to add a new wallet with that CAT: @@ -348,7 +346,6 @@ The first few tokens listed will be there by default (Marmot, Spacebucks, etc).
Enable new CAT
-
You will now see your token in your wallet with the full issued quantity. As a reminder, this should be the number of mojos spent divided by 1,000 (as each CAT token requires 1,000 mojos to issue). @@ -356,7 +353,6 @@ You will now see your token in your wallet with the full issued quantity. As a r
View new CAT
-
You now have access to your CAT in the GUI. You can send and receive your new tokens just like you would with regular XCH. @@ -386,7 +382,9 @@ This would be a complex and time-consuming process that would likely result in p ::: :::tip -You can generate keys from the CLI as well. Use `chia keys show` to see your available keys. Take note of their fingerprint as you will want to _not_ use an existing key. Generate a key with `chia keys generate`, followed by `chia keys show --show-mnemonic-seed` to reveal the 24 words. +You can generate keys from the CLI as well. +Use `chia keys show` to see your available keys. Take note of their fingerprint as you will want to _not_ use an existing key. +Generate a key with `chia keys generate`, followed by `chia keys show --show-mnemonic-seed` to reveal the 24 words. ::: Copy your new key pair's **mnemonic seed (24 secret words)** to a secure offline location. These 24 words are all you'll need to restore your wallet in the future. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-issuance.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-issuance.md index a456565c45..041427d9bf 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-issuance.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-issuance.md @@ -31,15 +31,15 @@ Now that you have a CSV file containing the necessary information, you can run t 1. Open a new terminal window and run the following to clone the CAT Admin Tool repository, using the `main` branch: - ```bash - git clone https://github.com/Chia-Network/CAT-admin-tool.git -b main - ``` +```bash +git clone https://github.com/Chia-Network/CAT-admin-tool.git -b main +``` 2. Change to the cloned repository: - ```bash - cd CAT-admin-tool - ``` +```bash +cd CAT-admin-tool +``` 3. Create a new virtual environment and then activate it: @@ -60,22 +60,22 @@ python -m venv venv - -```bash + + ```bash python3 -m venv venv . ./venv/bin/activate -``` - + ``` + - -```bash + + ```bash python3 -m venv venv . ./venv/bin/activate -``` - + ``` + - + 4. Install the latest versions of `pip`, `setuptools` and `wheel`: @@ -95,37 +95,36 @@ python -m pip install --upgrade pip setuptools wheel - -```bash + + ```bash python3 -m pip install --upgrade pip setuptools wheel ``` - + - -```bash + + ```bash python3 -m pip install --upgrade pip setuptools wheel ``` - + - + 5. Install the CAT Admin Tool: - ```bash - pip install . +```bash +pip install . +pip install . pip install chia-dev-tools --no-deps pip install pytest - ``` +``` - :::note You can safely ignore the following errors: +:::note You can safely ignore the following errors: - ``` - ERROR: Failed building wheel for CAT-admin-tool +``` +ERROR: Failed building wheel for CAT-admin-tool ERROR: pip's dependency resolver... - ``` - - ::: +``` :::tip Python 3.9+ may be required on macOS @@ -133,12 +132,12 @@ Python 3.9+ may be required on macOS 6. The CAT Admin Tool should now be installed and configured properly. To test it, run: - ```bash - cats --help +```bash +cats --help cdv --help - ``` +``` - You should get a usage statement for each command. At this point, you're ready to create your new CAT2 coins. +You should get a usage statement for each command. At this point, you're ready to create your new CAT2 coins. ## Secure the Bag (Single Issuance) {#secure-single} @@ -151,10 +150,10 @@ This section will show you how to create a tree of CAT2 coins that are identical If you are unsure whether your CAT used a single- or multi-issuance TAIL, step 1 will show you how to view the TAIL that was used to create it. 1. Figure out the total number of XCH mojos that were issued for your CAT1. - - Navigate to [taildatabase.com](https://www.taildatabase.com). - - Search for your CAT. We'll use Spacebucks for this example. - - You'll see _Supply_ (and a number) under the title on the right side of your screen. The number indicates the number of tokens issued. However, you need to multiply this number by 1,000 in order to calculate the number of XCH mojos used for the issuance. For example, Spacebucks had an issuance of 1 billion (1,000,000,000) tokens, which is equivalent to 1 trillion (1,000,000,000,000) XCH mojos. +- Navigate to [taildatabase.com](https://www.taildatabase.com). +- Search for your CAT. We'll use Spacebucks for this example. +- You'll see _Supply_ (and a number) under the title on the right side of your screen. The number indicates the number of tokens issued. However, you need to multiply this number by 1,000 in order to calculate the number of XCH mojos used for the issuance. For example, Spacebucks had an issuance of 1 billion (1,000,000,000) tokens, which is equivalent to 1 trillion (1,000,000,000,000) XCH mojos. - Click the _Chialisp_ button. This will show you the TAIL that was used for issuance. If it was a single-issuance CAT, it likely used `genesis_by_coin_id`. If you are unsure, compare the TAIL shown with the [TAIL in GitHub](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/genesis_by_coin_id.clvm). Take note of this TAIL as you will need to input its hex version in a subsequent step (if you used one of our reference TAILs, then you already have a copy of this file). 2. Sync a Chia wallet that has at least as many XCH mojos as the original issuance. @@ -169,21 +168,21 @@ If you are unsure whether your CAT used a single- or multi-issuance TAIL, step 1 3. Use the CAT Admin Tool to select a coin that will be used for issuing the CAT2 tokens. - From a terminal window you'll need to run the `cats` command. The arguments needed for this command include: +From a terminal window you'll need to run the `cats` command. The arguments needed for this command include: - - `--tail` – The TAIL program that was originally used (usually this is `genesis_by_coin_id`), in hex file format. - - `--send-to` – Where to send the tokens when they are initially issued. This is a placeholder only – you can enter any XCH address here. The value is required, but it will be ignored. - - `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. - - `--as-bytes` – This tells the tool to output the spend bundle in bytes instead of JSON. - - `--select-coin` – This tells the tool to select a specific coin from your wallet. +- `--tail` – The TAIL program that was originally used (usually this is `genesis_by_coin_id`), in hex file format. +- `--send-to` – Where to send the tokens when they are initially issued. This is a placeholder only – you can enter any XCH address here. The value is required, but it will be ignored. +- `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. +- `--as-bytes` – This tells the tool to output the spend bundle in bytes instead of JSON. +- `--select-coin` – This tells the tool to select a specific coin from your wallet. - The command to run is: +The command to run is: - ```bash - cats --tail --send-to
--amount --as-bytes --select-coin - ``` +```bash +cats --tail --send-to
--amount --as-bytes --select-coin +``` - Here's an example of the command to reissue Spacebucks: +Here's an example of the command to reissue Spacebucks: - -```bash -cats --tail ./reference_tails/genesis_by_coin_id.clsp.hex --send-to xch1rh6punh4fy70y80ef4g89c9hqvm54dtl0fvyc4ejdccp3y6p04fqn5x8x8 --amount 1000000000000 --as-bytes --select-coin + + ```bash +cats --tail ./reference_tails/delegated_tail.clsp.hex --curry 0x8a7afe10d00899b94cf0d407b85e1b9fca21868bcf158563fe9432b60e36db7136055186221fbd27ecc7fc0d5b99ef1b --send-to xch1rd7hejemt57amqtxq8azqg90hgxyhd9shwyjuppq5ez2jn4rlznscn4efy --amount 6000000000 --as-bytes --solution "(a (q 2 (i 47 (q 8) (q 2 (i (= 45 2) () (q 8)) 1)) 1) (c (q . 0x11038a7e107cb7e17a503ba201d94166018deecd777314e4697c5269d9f37fb6) 1))" --signature b75390ee21b001b7a721f719ff045e3dc2a1072ab0824a8e75c881398db0fbed8fde5c62bbdfe629dce5da3d77834559016acd6d403f9b90d3102da2e9452461457514088af0cabe0b8a8493fc9c09d1785f1322abc8958ecf7907eba0e0abcc ``` - + The last line of the output will be something like: @@ -226,18 +225,18 @@ This is the Coin ID of the coin that you will use for reissuance. Keep this valu 4. Obtain the target puzzle hash by running the "secure_the_bag" command. The important arguments here are: - - `--tail` – The TAIL program that was originally used (usually this is `genesis_by_coin_id`), in hex file format. - - `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. - - `--secure-the-bag-targets-path` – The full path to the CSV file that contains the snapshot of this CAT. - - `--curry` – The value of `Name:` from the above output. Note that you need to prepend `0x` to this argument, so for the above example, this value would start with `0x8f4`. +- `--tail` – The TAIL program that was originally used (usually this is `genesis_by_coin_id`), in hex file format. +- `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. +- `--secure-the-bag-targets-path` – The full path to the CSV file that contains the snapshot of this CAT. +- `--curry` – The value of `Name:` from the above output. Note that you need to prepend `0x` to this argument, so for the above example, this value would start with `0x8f4`. - The command to run is: +The command to run is: - ```bash - secure_the_bag --tail --amount --secure-the-bag-targets-path --prefix xch --curry - ``` +```bash +secure_the_bag --tail --amount --secure-the-bag-targets-path --prefix xch --curry +``` - Here's an example of the command to secure the bag for Spacebucks: +Here's an example of the command to secure the bag for Spacebucks: - + The command will create a tree of coins. This could take a long time, depending on how many coins need to be created. While it's in progress, it will output the percent complete. After it is finished, it will output the puzzle hash and address of the new coin to be created. @@ -283,15 +282,15 @@ You'll need both of these values later. 5. Push the transaction to the network. This will actually create the coin tree (_Secure the Bag_). The arguments are the same as above, with one exception: - `--send-to` – The XCH address from the "Secure the bag root address:" of the above output +`--send-to` – The XCH address from the "Secure the bag root address:" of the above output - The command to run is: +The command to run is: - ```bash - cats --tail --send-to --amount --as-bytes --curry <0x Coin ID> - ``` +```bash +cats --tail --send-to --amount --as-bytes --curry <0x Coin ID> +``` - For this example, the command looks like this: +For this example, the command looks like this: - + You will need to confirm that you want to push the transaction, then you will receive the `Asset ID` and `Eve Coin ID`. For this example, the following was the result: @@ -351,10 +350,10 @@ You need to use the same public/private key pair to sign the CAT2 issuance as yo 1. Figure out the total number of XCH mojos that were issued for your CAT1. - - Navigate to [taildatabase.com](https://www.taildatabase.com). - - Search for your CAT. - - You'll see _Supply_ (and a number) under the title on the right side of your screen. The number indicates the number of tokens issued. However, you need to multiply this number by 1,000 in order to calculate the number of XCH mojos used for the issuance. In this example, we'll use an issuance of 6 million (6,000,000) tokens, which is equivalent to 6 billion (6,000,000,000) XCH mojos. - - Click the _Chialisp_ button. This will show you the TAIL that was used for issuance. If it was a multi-issuance CAT, it likely used `delegated_tail`. If you are unsure, compare the TAIL shown with the [TAIL in GitHub](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/delegated_tail.clvm). Take note of this TAIL as you will need to input its hex version in a subsequent step (if you used one of our reference TAILs, then you already have a copy of this file). +- Navigate to [taildatabase.com](https://www.taildatabase.com). +- Search for your CAT. +- You'll see _Supply_ (and a number) under the title on the right side of your screen. The number indicates the number of tokens issued. However, you need to multiply this number by 1,000 in order to calculate the number of XCH mojos used for the issuance. In this example, we'll use an issuance of 6 million (6,000,000) tokens, which is equivalent to 6 billion (6,000,000,000) XCH mojos. +- Click the _Chialisp_ button. This will show you the TAIL that was used for issuance. If it was a multi-issuance CAT, it likely used `delegated_tail`. If you are unsure, compare the TAIL shown with the [TAIL in GitHub](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/delegated_tail.clvm). Take note of this TAIL as you will need to input its hex version in a subsequent step (if you used one of our reference TAILs, then you already have a copy of this file). 2. Sync a Chia wallet that has at least as many XCH mojos as the original issuance. @@ -368,21 +367,21 @@ You need to use the same public/private key pair to sign the CAT2 issuance as yo 3. Use the CAT Admin Tool to select a coin that will be used for issuing the CAT2 tokens. - From a terminal window you'll need to run the `cats` command. The arguments needed for this command include: +From a terminal window you'll need to run the `cats` command. The arguments needed for this command include: - - `--tail` – The TAIL program that was originally used (usually this is `delegated_tail`), in hex file format. - - `--send-to` – Where to send the tokens when they are initially issued. This is a placeholder only – you can enter any XCH address here. The value is required, but it will be ignored. - - `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. - - `--as-bytes` – This tells the tool to output the spend bundle in bytes instead of JSON. - - `--select-coin` – This tells the tool to select a specific coin from your wallet. +- `--tail` – The TAIL program that was originally used (usually this is `delegated_tail`), in hex file format. +- `--send-to` – Where to send the tokens when they are initially issued. This is a placeholder only – you can enter any XCH address here. The value is required, but it will be ignored. +- `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. +- `--as-bytes` – This tells the tool to output the spend bundle in bytes instead of JSON. +- `--select-coin` – This tells the tool to select a specific coin from your wallet. - The command to run is: +The command to run is: - ```bash - cats --tail --send-to
--amount --as-bytes --select-coin - ``` +```bash +cats --tail --send-to
--amount --as-bytes --select-coin +``` - Here's an example of the command: +Here's an example of the command: - + The last line of the output will be something like: @@ -425,18 +424,18 @@ This is the Coin ID of the coin that you will use for reissuance. Keep this valu 4. Obtain the target puzzle hash by running the "secure_the_bag" command. The important arguments here are: - - `--tail` – The TAIL program that was originally used (usually this is `delegated_tail`), in hex file format. - - `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. - - `--secure-the-bag-targets-path` – The full path to the CSV file that contains the snapshot of this CAT. - - `--curry` – The value of `Name:` from the above output. Note that you need to prepend `0x` to this argument, so for the above example, this value would start with `0x110`. +- `--tail` – The TAIL program that was originally used (usually this is `delegated_tail`), in hex file format. +- `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. +- `--secure-the-bag-targets-path` – The full path to the CSV file that contains the snapshot of this CAT. +- `--curry` – The value of `Name:` from the above output. Note that you need to prepend `0x` to this argument, so for the above example, this value would start with `0x110`. - The command to run is: +The command to run is: - ```bash - secure_the_bag --tail --amount --secure-the-bag-targets-path --prefix xch --curry - ``` +```bash +secure_the_bag --tail --amount --secure-the-bag-targets-path --prefix xch --curry +``` - Here's an example of the command to secure the bag: +Here's an example of the command to secure the bag: - + The command will create a tree of coins. This could take a long time, depending on how many coins need to be created. While it's in progress, it will output the percent complete. After it is finished, it will output the puzzle hash and address of the new coin to be created. @@ -482,13 +481,13 @@ You should now have obtained the `Secure the bag root puzzle hash` and the `Secu 5. Using the coin ID obtained from the `cats` command above, curry the ID into the `genesis_by_coin_id` puzzle. - The command to run is: +The command to run is: - ```bash - cdv clsp curry -a - ``` +```bash +cdv clsp curry -a +``` - In this example, the command will be: +In this example, the command will be: - + The output will be a new CLVM puzzle: @@ -560,7 +559,7 @@ cdv clsp curry ./reference_tails/genesis_by_coin_id.clsp.hex -a 0x11038a7e107cb7 ``` - + The output will be the treehash of the puzzle you calculated in the previous step: @@ -570,46 +569,46 @@ The output will be the treehash of the puzzle you calculated in the previous ste 7. Sign the treehash that you just calculated. This will effectively sign the puzzle containing the coin you selected. - The command to run is: +The command to run is: - ```bash - chia keys sign -d -f -t m -b - ``` +```bash +chia keys sign -d -f -t m -b +``` - Where `` is the fingerprint of the wallet that holds the coin you previously selected. This fingerprint can be obtained by running `chia keys show`. +Where `` is the fingerprint of the wallet that holds the coin you previously selected. This fingerprint can be obtained by running `chia keys show`. - For this example, the command is: +For this example, the command is: - ```bash - chia keys sign -d 3a56fa8cdf70dfd0e894af58359d72cb04658a1b0628a4ffe0dcc02099c9863b -f 1131363750 -t m -b - ``` +```bash +chia keys sign -d 3a56fa8cdf70dfd0e894af58359d72cb04658a1b0628a4ffe0dcc02099c9863b -f 1131363750 -t m -b +``` - The output will be the public key used for signing, as well as the signature obtained: +The output will be the public key used for signing, as well as the signature obtained: - ``` - Public key: 8a7afe10d00899b94cf0d407b85e1b9fca21868bcf158563fe9432b60e36db7136055186221fbd27ecc7fc0d5b99ef1b +``` +Public key: 8a7afe10d00899b94cf0d407b85e1b9fca21868bcf158563fe9432b60e36db7136055186221fbd27ecc7fc0d5b99ef1b Signature: b75390ee21b001b7a721f719ff045e3dc2a1072ab0824a8e75c881398db0fbed8fde5c62bbdfe629dce5da3d77834559016acd6d403f9b90d3102da2e9452461457514088af0cabe0b8a8493fc9c09d1785f1322abc8958ecf7907eba0e0abcc - ``` +``` 8. The final step is to create the coin using the `secure the bag root address` as the target address. - The command to run is: +The command to run is: - ``` - cats --tail --curry --send-to --amount --as-bytes --solution "" --signature - ``` +``` +cats --tail --curry --send-to --amount --as-bytes --solution "" --signature +``` - The arguments needed are: +The arguments needed are: - - `--tail` – The TAIL program that was originally used (usually this is `delegated_tail`), in hex file format. - - `--curry` – The public key obtained in the previous step. Be sure to prefix it with `0x`. - - `--send-to` – The `secure the bag root address`, obtained from in a previous step. - - `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. - - `--as-bytes` – Output the spend bundle in bytes (don't change this). - - `--solution` – The output of the `curry` command from a previous step (in quotes). - - `--signature` – The signature obtained from the previous step. +- `--tail` – The TAIL program that was originally used (usually this is `delegated_tail`), in hex file format. +- `--curry` – The public key obtained in the previous step. Be sure to prefix it with `0x`. +- `--send-to` – The `secure the bag root address`, obtained from in a previous step. +- `--amount` – The total number of mojos for this issuance. You need to have this many mojos in your wallet. This number must match the actual number of mojos that were originally issued. +- `--as-bytes` – Output the spend bundle in bytes (don't change this). +- `--solution` – The output of the `curry` command from a previous step (in quotes). +- `--signature` – The signature obtained from the previous step. - For this example, the command to execute is: +For this example, the command to execute is: - + The output of this command will contain the Asset ID and Eve Coin ID for your issuance: @@ -710,7 +709,7 @@ unwind_the_bag --eve-coin-id 9fe3e95308949cb9c49333f829922dc7118cd3e2fdf365cde66 ``` - + This command could take a long time to finish running. Afterward, you will have an exact copy of your CAT1 issuance, but in CAT2 form. @@ -726,50 +725,50 @@ At this point, you can navigate to [taildatabase.com](https://www.taildatabase.c 1. We used Spacebucks in the single-issuance example, so we'll obtain the puzzle hash of a wallet that contains some CAT1 Spacebucks. First, run: - ```bash - chia keys show - ``` +```bash +chia keys show +``` - This will show the `First wallet address` of the key pair that contains Spacebucks: +This will show the `First wallet address` of the key pair that contains Spacebucks: - ``` - First wallet address: xch1qzz5xrd05698f2n2tt4qm500kys6p4w79ph7s2xrlau3drfugl3qqh9j4l - ``` +``` +First wallet address: xch1qzz5xrd05698f2n2tt4qm500kys6p4w79ph7s2xrlau3drfugl3qqh9j4l +``` 2. Use the `cdv decode` command to obtain the puzzle hash that corresponds to this wallet address: - ```bash - cdv decode xch1qzz5xrd05698f2n2tt4qm500kys6p4w79ph7s2xrlau3drfugl3qqh9j4l - ``` +```bash +cdv decode xch1qzz5xrd05698f2n2tt4qm500kys6p4w79ph7s2xrlau3drfugl3qqh9j4l +``` - Which outputs: +Which outputs: - ``` - 0085430dafa68a74aa6a5aea0dd1efb121a0d5de286fe828c3ff79168d3c47e2 - ``` +``` +0085430dafa68a74aa6a5aea0dd1efb121a0d5de286fe828c3ff79168d3c47e2 +``` 3. If you want to verify that the puzzle hash is actually due to receive some tokens, you can check the CSV file. In this case, puzzle hash `0085...` should receive 42 thousand (42,000) barfs. 4. Run the `unwind_the_bag` command to send the appropriate amount to that puzzle hash. Be sure to run this command from the wallet that has the appropriate funds in it. - The important values for this command are: +The important values for this command are: - - `--eve-coin-id` – Obtained from the final "secure the bag" command above. - - `--tail-hash` – The `Asset ID:` from the final "secure the bag" command above. - - `--secure-the-bag-targets-path` – The full path to the CSV file that contains the snapshot of this CAT. - - `--unwind-fee` – An optional blockchain fee in mojos, will be applied to each spend. - - `--wallet-id` – The ID of the wallet from which to unwind (typically `1`). - - `--unwind-target-puzzle-hash` – The puzzle hash obtained from the `cdv decode` command above. +- `--eve-coin-id` – Obtained from the final "secure the bag" command above. +- `--tail-hash` – The `Asset ID:` from the final "secure the bag" command above. +- `--secure-the-bag-targets-path` – The full path to the CSV file that contains the snapshot of this CAT. +- `--unwind-fee` – An optional blockchain fee in mojos, will be applied to each spend. +- `--wallet-id` – The ID of the wallet from which to unwind (typically `1`). +- `--unwind-target-puzzle-hash` – The puzzle hash obtained from the `cdv decode` command above. - The command to run is: +The command to run is: - ```bash - unwind_the_bag --eve-coin-id --tail-hash --secure-the-bag-targets-path --unwind-fee --wallet-id --unwind-target-puzzle-hash - ``` +```bash +unwind_the_bag --eve-coin-id --tail-hash --secure-the-bag-targets-path --unwind-fee --wallet-id --unwind-target-puzzle-hash +``` - You may have noticed that this command is identical to [the command that unwinds the whole bag](#unwind), with the addition of the `--unwind-target-puzzle-hash` flag that ensures only coins are sent to a specific address. +You may have noticed that this command is identical to [the command that unwinds the whole bag](#unwind), with the addition of the `--unwind-target-puzzle-hash` flag that ensures only coins are sent to a specific address. - In this example, the command to unwind the bag is: +In this example, the command to unwind the bag is: - + This command could take a long time, depending on the total number of coins to unwind. You will need to verify the spend of each individual coin to unwind, and the command will monitor the blockchain for the coin(s) to be spent. The end result should be that the appropriate number of coins are sent to the puzzle hash, which you can then verify in your Chia wallet (assuming you control that wallet). :::note -Each puzzle hash in the bag can only receive one airdrop. When you later unwind the bag for each puzzle hash, any puzzle hashes that have already received an airdrop will be skipped. They will _not_ receive a second airdrop. +Each puzzle hash in the bag can only receive one airdrop. When you later unwind the bag for each puzzle hash, any puzzle hashes that have already received an airdrop will be skipped. They will _not_ receive a second airdrop. ::: When you later unwind the bag for each puzzle hash, any puzzle hashes that have already received an airdrop will be skipped. They will _not_ receive a second airdrop. ::: 5. The puzzle hashes from the CSV file are actually _inner_ puzzle hashes, so searching for them on chain using `cdv rpc coinrecords` is more complex than it normally would be. However, you can still verify that the bag was successfully unwound for that puzzle hash by searching for the hint: @@ -841,7 +840,7 @@ chia rpc full_node get_coin_records_by_hint '{"hint": " - + You should see matching coin_records for each entry in the CSV file, along with its corresponding value. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-snapshot.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-snapshot.md index 13985c6cae..e8c6538d78 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-snapshot.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-snapshot.md @@ -44,18 +44,17 @@ values={[ ]}> -1. If you previously installed Chia from a **binary build**, then set up an alias to the `chia` command: +- If you previously installed Chia from a **binary build**, then set up an alias to the `chia` command: :::caution Ensure that you replace `` and `` with the actual folders - ::: ```powershell Set-Alias -Name chia "C:\Users\\AppData\Local\chia-blockchain\app-\resources\app.asar.unpacked\daemon\chia.exe" ``` -2. If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: +- If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: ```powershell .\venv\Scripts\Activate.ps1 @@ -64,9 +63,9 @@ Set-Alias -Name chia "C:\Users\\AppData\Local\chia-blockchain\app- -1. If you previously installed Chia from a **binary build**, then ensure that the `chia` binary's directory is included in your `PATH`. +- If you previously installed Chia from a **binary build**, then ensure that the `chia` binary's directory is included in your `PATH`. -2. If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: +- If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: ```bash . ./activate @@ -75,13 +74,13 @@ Set-Alias -Name chia "C:\Users\\AppData\Local\chia-blockchain\app- -1. If you previously installed Chia from a **binary build**, then set up an alias to the `chia` command: +- If you previously installed Chia from a **binary build**, then set up an alias to the `chia` command: ```bash alias chia="/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/chia" ``` -2. If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: +- If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: ```bash . ./activate @@ -111,11 +110,11 @@ alias chia="/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/c 3. `START_HEIGHT` - The height of the blockchain to start creating the snapshot from (default: `0`). If you are attempting to obtain all records for your CAT, the recommended start height is `1146800`, which is just before CAT1 was introduced. 4. `TARGET_HEIGHT` - The height of the blockchain to end the snapshot (no default - must be set). The recommended height is `2311760`, which is the last block at which CAT1 is valid. -:::caution -Running this process with the recommended block heights could take over 40 hours to complete. You may wish to test it first by setting the `TARGET_HEIGHT` to `1146900`. This will pull data from only 100 blocks, which should only take a few seconds. -::: + :::caution + Running this process with the recommended block heights could take over 40 hours to complete. You may wish to test it first by setting the `TARGET_HEIGHT` to `1146900`. This will pull data from only 100 blocks, which should only take a few seconds. + ::: -In order to set these variables, you are recommended to put them into a file called `.env` at the root of the `CAT-addresses` project. The tool will automatically read the variables in this file. For example: + In order to set these variables, you are recommended to put them into a file called `.env` at the root of the `CAT-addresses` project. The tool will automatically read the variables in this file. For example: Authorized provider VC
-
#### VC Holder Wallet -- Holds a VC with launcher ID `5b5389e77b7ec8e9ebd7d92136254418ca674e382031d29aaa6ab75b7822792b` and two proofs: `test_proof1` and `test_proof2`. This VC was provided by the Authorized Provider wallet. +- Holds a VC with launcher ID `5b5389e77b7ec8e9ebd7d92136254418ca674e382031d29aaa6ab75b7822792b` and two proofs: `test_proof1` and `test_proof2`. This VC was provided by the Authorized Provider wallet. This VC was provided by the Authorized Provider wallet. - Does not own a DID - This wallet will receive some CR-CATs from the Authorized Provider @@ -182,7 +181,6 @@ The VC is also viewable from the GUI:
Holder VC
-
#### XCH Wallet @@ -205,7 +203,7 @@ Chia Wallet: ### CAT Admin Tool -CR-CATS are issued from the CAT-admin-tool repository. Follow the instructions below to install it for your specific OS: +CR-CATS are issued from the CAT-admin-tool repository. Follow the instructions below to install it for your specific OS: Follow the instructions below to install it for your specific OS: `, or `-c 0x1d9cb45618bdd9d70a0959ab8d91cafcbc1acbf7bd31a9e5286fd30622796783` in this example. :::warning important -When minting CR-CATs with the commands from this tutorial, you must prepend `0x` to the coin ID in the following command. If you fail to do this, the command will appear to succeed, but it will actually fail. The reasons for not showing an error are twofold: +When minting CR-CATs with the commands from this tutorial, you must prepend `0x` to the coin ID in the following command. If you fail to do this, the command will appear to succeed, but it will actually fail. The reasons for not showing an error are twofold: If you fail to do this, the command will appear to succeed, but it will actually fail. The reasons for not showing an error are twofold: 1. You are technically allowed to curry anything with this command's underlying CLVM puzzle, so omitting the `0x` is valid syntax, even though it won't work in this case. 2. The wallet client asynchronously sends the command to the node, so the wallet client does not know when the command fails. @@ -438,13 +436,13 @@ For example, this command will mint the CR-CATs using the `-c` option: cats -l ./reference_tails/genesis_by_coin_id.clsp.hex -t txch1yx4tdtqksjh7mk84deglwyq4j8td8jchyc8sdgem2hnuulmhzdhqct9wpr -a 1000000 -m 100000000 -d did:chia:1w4gf5eyensd37xa0x7aj27fe4cr9tqmf46m272suve5n4q2draesd0t54c -v "test_proof1" -c 0x1d9cb45618bdd9d70a0959ab8d91cafcbc1acbf7bd31a9e5286fd30622796783 ``` -As a result, a new spend bundle will be created for the minting. You will be prompted whether to submit it to the network: +As a result, a new spend bundle will be created for the minting. You will be prompted whether to submit it to the network: You will be prompted whether to submit it to the network: ```bash The transaction has been created, would you like to push it to the network? (Y/N) ``` -Respond with `Y` and you should be shown the `Asset ID` and `Eve Coin ID` for this CR-CAT. For example: +Respond with `Y` and you should be shown the `Asset ID` and `Eve Coin ID` for this CR-CAT. For example: For example: ```bash Successfully pushed the transaction to the network @@ -480,14 +478,13 @@ This information is also viewable in the GUI:
CR-CAT issuance
-
-The Authorized Provider now has control of all 1000 of the issued CR-CATs. This type of CAT is distinguished in the GUI by a padlock icon and `Restricted CAT`. The Authorized Provider also possesses a VC with the required proof (`test_proof1`), so a green icon appears when viewing the CAT. +The Authorized Provider now has control of all 1000 of the issued CR-CATs. This type of CAT is distinguished in the GUI by a padlock icon and `Restricted CAT`. The Authorized Provider now has control of all 1000 of the issued CR-CATs. This type of CAT is distinguished in the GUI by a padlock icon and `Restricted CAT`. The Authorized Provider also possesses a VC with the required proof (`test_proof1`), so a green icon appears when viewing the CAT. ## Send CR-CATs -Now that you have minted the CR-CATs, you can send them elsewhere. First, we'll send some to the VC Holder's wallet, which already has a VC that contains the required proof. +Now that you have minted the CR-CATs, you can send them elsewhere. Now that you have minted the CR-CATs, you can send them elsewhere. First, we'll send some to the VC Holder's wallet, which already has a VC that contains the required proof. ### Sending from the GUI @@ -496,7 +493,6 @@ You can send CR-CATs just as you would with regular CATs:
CR-CAT send
-
You should see a "success" message: @@ -504,7 +500,6 @@ You should see a "success" message:
CR-CAT send success
-
In this example, the recipient is the VC Holder's wallet. This wallet holds the credential with the required proof (`test_proof1`) for holding this CR-CAT. Because the proof exists, a green `APPROVE` button will appear. @@ -514,15 +509,13 @@ From the VC Holder's wallet, click this button to finalize the transaction:
VC Holder Approve
-
-An on-chain transaction is required for the approval to be processed. This is necessary to guard against unauthorized wallets holding CR-CATs, as will be demonstrated later in this tutorial. Enter a transaction fee and click `APPROVE PENDING TRANSACTIONS`: +An on-chain transaction is required for the approval to be processed. An on-chain transaction is required for the approval to be processed. This is necessary to guard against unauthorized wallets holding CR-CATs, as will be demonstrated later in this tutorial. Enter a transaction fee and click `APPROVE PENDING TRANSACTIONS`: Enter a transaction fee and click `APPROVE PENDING TRANSACTIONS`:
Approve pending transactions
-
After the transaction has been processed, the CR-CATs will become available to the VC Holder, who can now send or trade them just like normal CATs. @@ -530,7 +523,6 @@ After the transaction has been processed, the CR-CATs will become available to t
CR-CAT approved
-
### Sending from the CLI @@ -548,7 +540,7 @@ CAT 3ba9e16dca39f3fb...: -Wallet ID: 5 ``` -From the CLI, run a standard `send` command. In this example, we will use the following flags: +From the CLI, run a standard `send` command. In this example, we will use the following flags: In this example, we will use the following flags: - `-i` -- The `Wallet ID` of the CR-CAT - `-a` -- The number of CR-CATs to send @@ -567,7 +559,7 @@ Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c991 Run 'chia wallet get_transaction -f 3152280463 -tx 0xab577bdce7fdd1be8b4e0634ad69aa5cff66f6d9dc7d26e0119d1a3a740f91e8' to get status ``` -After a few minutes, run the command from the previous command's output to view the transaction. For example: +After a few minutes, run the command from the previous command's output to view the transaction. For example: For example: ```bash chia wallet get_transaction -f 3152280463 -tx 0xab577bdce7fdd1be8b4e0634ad69aa5cff66f6d9dc7d26e0119d1a3a740f91e8 @@ -618,7 +610,7 @@ CAT 3ba9e16dca39f3fb...: -Wallet ID: 3 ``` -The VC Holder still needs to approve the new CR-CATs in order to add them to the wallet balance. This is accomplished with the `approve_r_cats` command. In this example, we will use the following flags: +The VC Holder still needs to approve the new CR-CATs in order to add them to the wallet balance. This is accomplished with the `approve_r_cats` command. In this example, we will use the following flags: This is accomplished with the `approve_r_cats` command. In this example, we will use the following flags: - `-i` -- The `Wallet ID` of the CR-CAT - `-a` -- The amount to approve @@ -677,48 +669,43 @@ In this example, as the **Authorized Provider**, click `CREATE AN OFFER` from th
Create an Offer
-
-Next, fill out the Offer Builder. For this example, we will offer to trade 99 CR-CATs for 0.1 TXCH: +Next, fill out the Offer Builder. Next, fill out the Offer Builder. For this example, we will offer to trade 99 CR-CATs for 0.1 TXCH:
Offer Builder
-
After creating the Offer, Authorized Provider can save it as a local file or post it to a marketplace. -For this example, we will change to the **VC Holder** wallet and load the Offer file. This wallet contains a VC with the required proof to hold this CR-CAT (`test_proof1`). Enter an optional blockchain fee and click `ACCEPT OFFER`: +For this example, we will change to the **VC Holder** wallet and load the Offer file. This wallet contains a VC with the required proof to hold this CR-CAT (`test_proof1`). Enter an optional blockchain fee and click `ACCEPT OFFER`: In this example, the recipient is the VC Holder's wallet. This wallet holds the credential with the required proof (`test_proof1`) for holding this CR-CAT. Because the proof exists, a green `APPROVE` button will appear. Enter an optional blockchain fee and click `ACCEPT OFFER`:
Accept Offer
-
-While the on-chain transaction to accept the Offer is pending, the 99 CR-CATs will be displayed in the VC Holder's `Pending Balance`. Note that the `Pending Balance for Approval` is `0` in this case: +While the on-chain transaction to accept the Offer is pending, the 99 CR-CATs will be displayed in the VC Holder's `Pending Balance`. Note that the `Pending Balance for Approval` is `0` in this case: Note that the `Pending Balance for Approval` is `0` in this case:
Pending Offer Acceptance
-
-After the transaction has been confirmed, the balance is updated. When receiving CR-CATs via an Offer, there is no need to perform another transaction to approve of the incoming tokens. This is because the proof requirement is already baked into the Offer file. +After the transaction has been confirmed, the balance is updated. After the transaction has been confirmed, the balance is updated. When receiving CR-CATs via an Offer, there is no need to perform another transaction to approve of the incoming tokens. This is because the proof requirement is already baked into the Offer file. This is because the proof requirement is already baked into the Offer file.
Completed Offer
-
At this point, the VC Holder wallet has full possession of the CR-CATs. ### CLI Offers -Offers for CR-CATs can also be created and accepted via the CLI. For this example, the **Authorized Provider** will create an Offer using the following flags: +Offers for CR-CATs can also be created and accepted via the CLI. Offers for CR-CATs can also be created and accepted via the CLI. For this example, the **Authorized Provider** will create an Offer using the following flags: - `-o` -- The Offer amount, using the syntax ``:`` - `-r` -- The requested amount, using the syntax ``:` Send CR-CATs to address lacking proofs -
-Even though the recipient is not allowed to hold these CR-CATs, the transaction itself is valid. However, just as in the examples at the beginning of this tutorial, the XCH Wallet will receive the CR-CATs in the `Pending Balance for Approval` section of the GUI. In this case, the required proof (in the red circle below) is not present. +Even though the recipient is not allowed to hold these CR-CATs, the transaction itself is valid. Even though the recipient is not allowed to hold these CR-CATs, the transaction itself is valid. However, just as in the examples at the beginning of this tutorial, the XCH Wallet will receive the CR-CATs in the `Pending Balance for Approval` section of the GUI. In this case, the required proof (in the red circle below) is not present. In this case, the required proof (in the red circle below) is not present. The XCH Wallet can still attempt to approve these CR-CATs:
Proof not present
-
Attempt to approve
-
However, this attempt will fail because the required proofs are missing: @@ -874,7 +858,6 @@ However, this attempt will fail because the required proofs are missing:
Required providers missing
-
The status of these CR-CATs is as follows: @@ -884,27 +867,26 @@ The status of these CR-CATs is as follows: - The XCH Wallet is not allowed to send them elsewhere - The Authorized Provider's wallet no longer holds them -Note that even though nothing can be done with the funds in this state, they are still not bricked. The XCH Wallet will gain access to the funds if it obtains a VC with the required proof. However, assuming the XCH Wallet was not supposed to hold the correct VC in the first place, the Authorized Provider will presumably be reluctant to issue a VC to this wallet. +Note that even though nothing can be done with the funds in this state, they are still not bricked. The XCH Wallet will gain access to the funds if it obtains a VC with the required proof. Note that even though nothing can be done with the funds in this state, they are still not bricked. The XCH Wallet will gain access to the funds if it obtains a VC with the required proof. However, assuming the XCH Wallet was not supposed to hold the correct VC in the first place, the Authorized Provider will presumably be reluctant to issue a VC to this wallet. :::info -For the reasons discussed above, exercise caution when sending CR-CATs to another wallet. In fact, because of the risk of making the funds difficult (if not impossible) to access, we recommend that you don't send CR-CATs in this way. +For the reasons discussed above, exercise caution when sending CR-CATs to another wallet. For the reasons discussed above, exercise caution when sending CR-CATs to another wallet. In fact, because of the risk of making the funds difficult (if not impossible) to access, we recommend that you don't send CR-CATs in this way. Instead, you should use Offers to distribute CR-CATs, as they provide two important advantages: -- If the recipient is allowed to hold the CR-CATs, they will be able to accept an Offer to receive those CATs. Once the Offer is complete, they will not need to submit an approval transaction. +- If the recipient is allowed to hold the CR-CATs, they will be able to accept an Offer to receive those CATs. Once the Offer is complete, they will not need to submit an approval transaction. Once the Offer is complete, they will not need to submit an approval transaction. - If the recipient is not allowed to hold the CR-CATs, they will not be able to accept an Offer to receive those CATs in the first place. ::: ### Offers for CR-CATs -Let's say the owner of the XCH Wallet locates a CR-CAT Offer. Upon viewing the offer, the wallet's owner will see that the required proof is grayed out, indicating that it is not present: +Let's say the owner of the XCH Wallet locates a CR-CAT Offer. Let's say the owner of the XCH Wallet locates a CR-CAT Offer. Upon viewing the offer, the wallet's owner will see that the required proof is grayed out, indicating that it is not present:
Offer where required providers missing
-
Any attempts to accept this Offer without first receiving a VC with the required proofs will fail: @@ -912,7 +894,6 @@ Any attempts to accept this Offer without first receiving a VC with the required
Offer acceptance where required providers missing
-
Thus, when using Offers, the funds cannot accidentally be sent to an unauthorized recipient. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-primitive-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-primitive-guide.md index ef9a719981..cc6e3591ca 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-primitive-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-primitive-guide.md @@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem'; ## Intro -This document will show you how to use Chia's standalone clawback primitive. 欢迎钱包开发者将其整合到开发的GUI钱包中。 +This document will show you how to use Chia's standalone clawback primitive. 欢迎钱包开发者将其整合到开发的GUI钱包中。 欢迎钱包开发者将其整合到开发的GUI钱包中。 有关其他技术资源，请参阅以下内容： @@ -18,17 +18,17 @@ This document will show you how to use Chia's standalone clawback primitive. 欢 :::warning 一些重要提醒 -- The standalone clawback primitive doesn't implement wallet functionality to handle incoming clawbacks and resync deleted coin stores. Rather, it's for developers to understand the process of how clawbacks work. -- Chia Network, Inc has added a user-friendly implementation of the clawback primitive to version 1.8.2 of the reference wallet. +- The standalone clawback primitive doesn't implement wallet functionality to handle incoming clawbacks and resync deleted coin stores. Rather, it's for developers to understand the process of how clawbacks work. Rather, it's for developers to understand the process of how clawbacks work. +- Chia Network Inc has added a user-friendly implementation of the clawback primitive to version 1.8.2 of the reference wallet. - A **synced full node** AND a synced wallet are required to use the clawback primitive. -- You are recommended to test the clawback primitive on either the testnet or a simulator before moving to mainnet. For your reference, this guide will use testnet10. +- You are recommended to test the clawback primitive on either the testnet or a simulator before moving to mainnet. For your reference, this guide will use a testnet. - The clawback primitive currently only supports XCH/TXCH. It does not support CATs or NFTs. The `-w` flag will be ignored if it points to a non-XCH (or TXCH) wallet. ::: --- -### 关于可撤回交易（clawback） +## 关于可撤回交易（clawback） 可撤回交易原语的目的是防止将Chia资产发送到一个错误的地址。 可撤回交易的原理很简单：它是一种中间硬币，直到时间锁定过期之前，无法发送到目标地址。 与此同时，发送者可以"撤回"该硬币，将其以标准XCH的形式退回到他们的钱包中。 @@ -43,7 +43,7 @@ This document will show you how to use Chia's standalone clawback primitive. 欢 - It contains Alice's address as its clawback destination (Alice -- and no one else -- can modify this later) - It contains Bob's address as its final destination (Bob -- and no one else -- can modify this later) - The clawback coin therefore contains the following logic for how it may be spent: - - Before 1 hour has elapsed since the coin's creation, Alice can use [p2_1_of_n](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/p2_m_of_n_delegate_direct.clvm) to spend the coin using the same public/private key pair that created the coin. When the coin is spent in this way, a new coin is created using [p2_puzzle_hash](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/p2_puzzle_hash.clvm). Typically, this coin will be created in Alice's wallet, but it could be created in another wallet instead. The new coin uses the standard Chia puzzle. This is the `clawback` case. + - Before 1 hour has elapsed since the coin's creation, Alice can use [p2_1_of_n](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/p2_m_of_n_delegate_direct.clvm) to spend the coin using the same public/private key pair that created the coin. When the coin is spent in this way, a new coin is created using [p2_puzzle_hash](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/p2_puzzle_hash.clvm). Typically, this coin will be created in Alice's wallet, but it could be created in another wallet instead. The new coin uses the standard Chia puzzle. This is the `clawback` case. When the coin is spent in this way, a new coin is created using [p2_puzzle_hash](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/p2_puzzle_hash.clvm). Typically, this coin will be created in Alice's wallet, but it could be created in another wallet instead. The new coin uses the standard Chia puzzle. This is the `clawback` case. - Before 1 hour has elapsed since the coin's creation, nobody other than Alice may spend it - After 1 hour, the timelock elapses. At this point Bob can spend the clawback coin. When this spend occurs, by default a new standard XCH coin is created in Bob's wallet. Bob can also pass in a different address than the one he originally specified if he so chooses. - Note that the coin's clawback logic is in place for the life of the coin. This means that until the coin is spent, Alice is able to claw it back. This is true regardless of the coin's age. Because of this, after the timelock expires, Bob must spend the clawback coin in order to receive the XCH in his wallet. After this spend has completed, the clawback coin no longer exists, and the spend is final. @@ -66,7 +66,7 @@ The values used in the commands from this guide are just examples. You will need --- -### Install the clawback primitive +## Install the clawback primitive The clawback primitive is included in the `Chia-Network` organization's `chia-clawback-primitive` GitHub repository. @@ -142,7 +142,7 @@ At this point, you are ready to use the clawback primitive. --- -### Create a clawback coin +## Create a clawback coin For this example, we will use two wallets: a Sender and a Recipient. The Sender has a balance of 10 TXCH and the Recipient has 0 TXCH. @@ -209,7 +209,7 @@ Timelock: 600 seconds Time left: 518 seconds ``` -### Claw back a coin +## Claw back a coin This guide will continue from the previous section, where we created a new clawback coin, which has not yet been spent. As a reminder, these are the clawback coin's details: @@ -280,7 +280,7 @@ Chia Wallet: At this point, the clawback coin no longer exists. The Sender is of course free to create new clawback coins as they see fit. -### Claim a clawback coin +## Claim a clawback coin In this section, we'll show how to claim a clawback coin. First, the Sender creates a new clawback coin with a 60-second timelock: @@ -392,7 +392,7 @@ However, there is a small window of time where the timer has expired, but a bloc You are trying to claim the coin too early ``` -In this case, the Recipient needs to wait for one more transaction block to be farmed before proceeding with the `claim` call. As a reminder, a new transaction block is farmed every 52 seconds, on average. +In this case, the Recipient needs to wait for one more transaction block to be farmed before proceeding with the `claim` call. As a reminder, a new transaction block is farmed every 52 seconds, on average. As a reminder, a new transaction block is farmed every 52 seconds, on average. ::: @@ -442,11 +442,11 @@ The spend is now complete and can no longer be clawed back. The funds are stored --- -### Other cases +## Other cases So far, we have shown the standard clawback and completion spends. There are also a few edge cases and errors worth discussing. -#### Sender performs a clawback after the timelock +### Sender performs a clawback after the timelock After the timelock expires, the Recipient may claim the clawback coin. Until this is done, the Sender can still claw back the coin. @@ -532,7 +532,7 @@ Chia Wallet: Because the Sender can always claw back a clawback coin while it exists, the Recipient cannot assume that they will receive the clawback coin, even after the timelock has expired. However, after the Recipient has claimed the clawback coin and it has appeared in the Recipient's wallet as regular XCH/TXCH, the coin can no longer be clawed back. -#### Recipient attempts to claim clawback coin before timelock has expired +### Recipient attempts to claim clawback coin before timelock has expired Before the timelock expires, a clawback coin may not be spent to its Recipient's address. For example, let's say the following clawback coin exists. Note that its `Time left:` is still greater than 0 seconds: @@ -564,7 +564,7 @@ Result: You are trying to claim the coin too early ``` -#### Someone other than the Sender attempts to claw back a coin +### Someone other than the Sender attempts to claw back a coin For this example, the Sender creates a new clawback coin: @@ -653,7 +653,7 @@ Traceback (most recent call last): ValueError: Couldn't find a matching key for puzzle hash: ee3144040e80747af2f6ec56ed7567d22ca83ea3470e09bb9d95347a80cd2d29. ``` -#### Someone other than the Recipient attempts to claim a clawback spend +### Someone other than the Recipient attempts to claim a clawback spend For this example, someone other than the Recipient is made aware of the Coin ID of a pending clawback coin: @@ -715,7 +715,7 @@ Traceback (most recent call last): ValueError: Couldn't find a matching key for puzzle hash: c08dfae2aab3b3b3cbffdd4c1f1e4bf2df278785e5ca67524d6e518e79f134c3. ``` -#### Sender claws back coin to a new wallet +### Sender claws back coin to a new wallet The Sender has the option of performing a clawback where the coin is sent to any wallet. Let's say the Sender creates a clawback coin: @@ -763,7 +763,7 @@ Chia Wallet: -Wallet ID: 1 ``` -#### Recipient claims a clawback coin in a new wallet address +### Recipient claims a clawback coin in a new wallet address The Recipient also has the option of spending a clawback coin to a new address. @@ -833,7 +833,7 @@ Chia Wallet: -Wallet ID: 1 ``` -#### Sender or Recipient attempts to show a clawback coin before it has been created +### Sender or Recipient attempts to show a clawback coin before it has been created Two important rules to keep in mind: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-user-guide.md index 62fcaa8bfe..9fd453a517 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-user-guide.md @@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem'; ## Intro -This document is a guide for using the clawback functionality introduced in version 1.8.2 of Chia's reference wallet. _Clawback_ is a new feature that offers protection against sending XCH to the wrong address. +This document is a guide for using the clawback functionality introduced in version 1.8.2 of Chia's reference wallet. This document is a guide for using the clawback functionality introduced in version 1.8.2 of Chia's reference wallet. _Clawback_ is a new feature that offers protection against sending XCH to the wrong address. If you are a developer or a CLI user, see the following resources for more info: @@ -18,8 +18,8 @@ If you are a developer or a CLI user, see the following resources for more info: In order to use Chia clawbacks, you must have: -- Version 1.8.2 or later of Chia's reference light wallet or full node. See our [downloads page](https://www.chia.net/downloads/) to obtain a copy. -- A sufficient amount of XCH or TXCH to send a transaction and pay fees. If you do not have a sufficient amount, you can obtain some from our [mainnet](https://faucet.chia.net/) and [testnet](https://testnet10-faucet.chia.net/) faucets. +- Version 1.8.2 or later of Chia's reference light wallet or full node. See our [downloads page](https://www.chia.net/downloads/) to obtain a copy. See our [downloads page](https://www.chia.net/downloads/) to obtain a copy. +- A sufficient amount of XCH or TXCH to send a transaction and pay fees. A sufficient amount of XCH or TXCH to send a transaction and pay fees. If you do not have a sufficient amount, you can obtain some from our [mainnet](https://faucet.chia.net/) and [testnet](https://testnet10-faucet.chia.net/) faucets. --- @@ -35,11 +35,11 @@ The following demonstrates an example workflow of this process: - The sender and receiver both see the pending 1-XCH transaction in their wallets - The sender can choose to return the 1 XCH to his/her wallet (this is a _clawback_) - The receiver cannot yet claim the money - - The sender and receiver could communicate off-chain. For example, the sender could call the receiver and ask if the pending transaction appears in their wallet. + - The sender and receiver could communicate off-chain. The sender and receiver could communicate off-chain. For example, the sender could call the receiver and ask if the pending transaction appears in their wallet. - If yes, then both parties can be confident that the money was sent to the correct address - If no, then the money was sent to an incorrect address, so the sender will claw it back 4. After 10 minutes, if the sender has not clawed the 1 XCH back, the receiver can claim it -5. After the receiver has claimed the money, it appears in both wallets as a normal transaction. At this point, the transaction is complete; clawback is no longer possible +5. After the receiver has claimed the money, it appears in both wallets as a normal transaction. At this point, the transaction is complete; clawback is no longer possible At this point, the transaction is final. It can no longer be clawed back. The "intermediate location" is actually a coin with two rules: @@ -56,7 +56,7 @@ This guide will show you how to perform the above workflow. ### Review Settings -Before initiating a clawback transaction, it's a good idea to review your wallet's settings. Click `Settings` (the gear icon in the lower-left corner of your wallet) and click the `CUSTODY` menu. +Before initiating a clawback transaction, it's a good idea to review your wallet's settings. Click `Settings` (the gear icon in the lower-left corner of your wallet) and click the `CUSTODY` menu. Click `Settings` (the gear icon in the lower-left corner of your wallet) and click the `CUSTODY` menu. From this menu: @@ -82,8 +82,8 @@ From the `SEND` menu as shown below, enter the recipient's address, the amount t :::note -- Prior to initiating the transaction, the sender's wallet from this example contained 5 TXCH. The amount to be sent was 1 TXCH. -- This example was executed on Chia's testnet, which has higher fee requirements than mainnet. For this reason, a large fee of 100 million mojos was added. +- Prior to initiating the transaction, the sender's wallet from this example contained 5 TXCH. The amount to be sent was 1 TXCH. The amount to be sent was 1 TXCH. +- This example was executed on Chia's testnet, which has higher fee requirements than mainnet. For this reason, a large fee of 100 million mojos was added. For this reason, a large fee of 100 million mojos was added. ::: @@ -100,7 +100,7 @@ After you have entered these parameters, click the dropdown for `Add option to c --- -Add the time (days, minutes, hours) during which the transaction will be able to be clawed back. In this case, we'll use 10 minutes. +Add the time (days, minutes, hours) during which the transaction will be able to be clawed back. In this case, we'll use 10 minutes. In this case, we'll use 10 minutes. Optionally add a memo to describe this transaction, and click `SEND`. @@ -115,7 +115,7 @@ Optionally add a memo to describe this transaction, and click `SEND`. --- -The transaction has been added to the mempool. This means that it is still in the `Pending` state for inclusion on the blockchain. At this point, there is no indication in the GUI that this is a clawback transaction. +The transaction has been added to the mempool. This means that it is still in the `Pending` state for inclusion on the blockchain. The transaction has been added to the mempool. This means that it is still in the `Pending` state for inclusion on the blockchain. At this point, there is no indication in the GUI that this is a clawback transaction.
-At this point, the transaction is final. The sender has the same amount of XCH they started with, minus the two transaction fees. Due to the clawback, the original "receiver" did not receive anything. +At this point, the transaction is final. At this point, the transaction is final. The sender has the same amount of XCH they started with, minus the two transaction fees. Due to the clawback, the original "receiver" did not receive anything. Due to the clawback, the original "receiver" did not receive anything. --- @@ -196,7 +196,7 @@ To avoid confusion, the sender's wallet in this example uses a light theme, and ::: -Just like before, start by creating a new transaction and adding a clawback time and an optional memo. We'll use 10 minutes in this example. +Just like before, start by creating a new transaction and adding a clawback time and an optional memo. We'll use 10 minutes in this example. We'll use 10 minutes in this example.
-u -nh -m ``` -This will include the wallet ID, URL, data hash, and a fee. If this command is issued successfully, you will have created an NFT on Chia! +This will include the wallet ID, URL, data hash, and a fee. +If this command is issued successfully, you will have created an NFT on Chia! You can get the details of your new NFT with: @@ -463,32 +465,32 @@ Response: ``` NFT minted Successfully with spend bundle: { - 'aggregated_signature': '0x8673a394dca82d91cd1ddeff0b518cb02056fa24ce45b8cda4e7819258c9cc13a68ed71d4d25ef7254358af2f033d99b180b2b0255a8f113d699517e7019b825b09f68eb126da228f82b474f316bc8a657310a527ff54a4668971e9486c39c89', - 'coin_solutions': [{ - 'coin': { - 'amount': 1, - 'parent_coin_info': '0x75690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8d', - 'puzzle_hash': '0xd41dce69252d14db9a19eb0fcbd0e014d416245460b76a9fe4e7a8030e1bb4c6' - }, - 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa075690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8da0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff04ff2cff8080808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a0a04d9f57764f54a43e4030befb4d80026e870519aaa66334aef8304f5d0393c2ffff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31313035333037322f706578656c732d70686f746f2d31313035333037322e6a70656780ffff68a014836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0ffff826d7580ffff826c7580ffff82736e01ffff8273740180ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff17ffff04ff0bffff04ffff02ff2fff5f80ff80808080808080ffff04ffff01ffffff82ad4cff0233ffff3e04ff81f601ffffff0102ffff02ffff03ff05ffff01ff02ff2affff04ff02ffff04ff0dffff04ffff0bff32ffff0bff3cff3480ffff0bff32ffff0bff32ffff0bff3cff2280ff0980ffff0bff32ff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ff04ffff04ff38ffff04ffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ffff02ff2effff04ff02ffff04ffff02ffff03ff81afffff0181afffff010b80ff0180ff80808080ffff04ffff0bff3cff4f80ffff04ffff0bff3cff0580ff8080808080808080ff378080ff82016f80ffffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff2fffff01ff80ff808080808080808080ff0bff32ffff0bff3cff2880ffff0bff32ffff0bff32ffff0bff3cff2280ff0580ffff0bff32ffff02ff2affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff5fffff01ff02ffff03ffff09ff82011fff3880ffff01ff02ffff03ffff09ffff18ff82059f80ff3c80ffff01ff02ffff03ffff20ff81bf80ffff01ff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff82019fffff04ff82017fff80808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff0180ffff01ff02ffff03ffff09ff82011fff2c80ffff01ff02ffff03ffff20ff82017f80ffff01ff04ffff04ff24ffff04ffff0eff10ffff02ff2effff04ff02ffff04ff82019fff8080808080ff808080ffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ffff02ff0bffff04ff17ffff04ff2fffff04ff82019fff8080808080ff8080808080808080808080ffff01ff088080ff0180ffff01ff02ffff03ffff09ff82011fff2480ffff01ff02ffff03ffff20ffff02ffff03ffff09ffff0122ffff0dff82029f8080ffff01ff02ffff03ffff09ffff0cff82029fff80ffff010280ff1080ffff01ff0101ff8080ff0180ff8080ff018080ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff8080808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff018080ff018080ff0180ffff01ff02ff3affff04ff02ffff04ff05ffff04ff0bffff04ff81bfffff04ffff02ffff03ff82017fffff0182017fffff01ff02ff0bffff04ff17ffff04ff2fffff01ff808080808080ff0180ff8080808080808080ff0180ff018080ffff04ffff01a0c5abea79afaa001b5427dfa0c8cf42ca6f38f5841b78f9b3c252733eb2de2726ffff04ffff0180ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff04ff82013fffff04ff80ffff04ffff02ffff03ffff22ff82013fffff20ffff09ff82013fff2f808080ffff01ff04ffff04ff10ffff04ffff0bffff02ff2effff04ff02ffff04ff09ffff04ff8205bfffff04ffff02ff3effff04ff02ffff04ffff04ff09ffff04ff82013fff1d8080ff80808080ff808080808080ff1580ff808080ffff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ffff01ff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ff0180ff80808080ffff01ff04ff2fffff01ff80ff80808080ff0180ffff04ffff01ffffff3f02ff04ff0101ffff822710ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff2cff1480ffff0bff2affff0bff2affff0bff2cff3c80ff0980ffff0bff2aff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ff17ffff01ff04ffff04ff10ffff04ffff0bff81a7ffff02ff3effff04ff02ffff04ffff04ff2fffff04ffff04ff05ffff04ffff05ffff14ffff12ff47ff0b80ff128080ffff04ffff04ff05ff8080ff80808080ff808080ff8080808080ff808080ffff02ff16ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fff8080808080808080ff8080ff0180ffff0bff2affff0bff2cff1880ffff0bff2affff0bff2affff0bff2cff3c80ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff3effff04ff02ffff04ff09ff80808080ffff02ff3effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa075690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8da0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01a0c05f74b4f7e8b79dbb23118d7bcdebcadbaddac46824acebe455481c3ec850daffff04ffff0180ff0180808080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0815cec38feefbc2669d2eab272deb4badc17bc42a0f1cecbf1f5cf8c0219d9b7cdad195b9588291642db49da17b99b6eff018080ff018080808080ff018080808080ff01808080', - 'solution': '0xffffa02f1c4f4568c420033fb690c134ed3ed3d8d9fa3bdb75f1044d51789b59ea3a1dff0180ff01ffffffff80ffff01ffff81f6ff80ff80ff8080ffff33ffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6ff01ffffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6ffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6808080ff8080808080' - }, { - 'coin': { - 'amount': 9734999999, - 'parent_coin_info': '0x265cee97bfc72cc1c41692c9462d098009f5bcade81202cfbacf717a988b8667', - 'puzzle_hash': '0x7b0628c573b77df18bf858b6111be39e25e040f4fdb74c74702dfd94b1bd7fbb' - }, - 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0aa1fdb303fb4e59c8082380e3462a0a4ff3f66ccfb5c40b33b6a13706206b1796f2a32c035a452a26d9926fccb0e3246ff018080', - 'solution': '0xff80ffff01ffff33ffa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ff0180ffff33ffa0e520db6f3cab1c1a26f84f6bb19f44c103a3609a2b552ed1e2647dbf600fd160ff85023474bb7e80ffff34ff840fcb944080ffff3cffa0a8520fb03d767496573596438ba3e9414cc845b1d2ab26c159ab64be397dd7ba80ffff3dffa05751070a5bfeabb3f71640bacfa81ea2275c36a25a60bb4381ef598cb56bca578080ff8080' - }, { - 'coin': { - 'amount': 1, - 'parent_coin_info': '0x2f1c4f4568c420033fb690c134ed3ed3d8d9fa3bdb75f1044d51789b59ea3a1d', - 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' - }, - 'puzzle_reveal': '0xff02ffff01ff04ffff04ff04ffff04ff05ffff04ff0bff80808080ffff04ffff04ff0affff04ffff02ff0effff04ff02ffff04ffff04ff05ffff04ff0bffff04ff17ff80808080ff80808080ff808080ff808080ffff04ffff01ff33ff3cff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff0effff04ff02ffff04ff09ff80808080ffff02ff0effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080', - 'solution': '0xffa0d41dce69252d14db9a19eb0fcbd0e014d416245460b76a9fe4e7a8030e1bb4c6ff01ff8080' - }] + 'aggregated_signature': '0x8673a394dca82d91cd1ddeff0b518cb02056fa24ce45b8cda4e7819258c9cc13a68ed71d4d25ef7254358af2f033d99b180b2b0255a8f113d699517e7019b825b09f68eb126da228f82b474f316bc8a657310a527ff54a4668971e9486c39c89', + 'coin_solutions': [{ + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x75690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8d', + 'puzzle_hash': '0xd41dce69252d14db9a19eb0fcbd0e014d416245460b76a9fe4e7a8030e1bb4c6' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa075690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8da0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff04ff2cff8080808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a0a04d9f57764f54a43e4030befb4d80026e870519aaa66334aef8304f5d0393c2ffff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31313035333037322f706578656c732d70686f746f2d31313035333037322e6a70656780ffff68a014836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0ffff826d7580ffff826c7580ffff82736e01ffff8273740180ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff17ffff04ff0bffff04ffff02ff2fff5f80ff80808080808080ffff04ffff01ffffff82ad4cff0233ffff3e04ff81f601ffffff0102ffff02ffff03ff05ffff01ff02ff2affff04ff02ffff04ff0dffff04ffff0bff32ffff0bff3cff3480ffff0bff32ffff0bff32ffff0bff3cff2280ff0980ffff0bff32ff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ff04ffff04ff38ffff04ffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ffff02ff2effff04ff02ffff04ffff02ffff03ff81afffff0181afffff010b80ff0180ff80808080ffff04ffff0bff3cff4f80ffff04ffff0bff3cff0580ff8080808080808080ff378080ff82016f80ffffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff2fffff01ff80ff808080808080808080ff0bff32ffff0bff3cff2880ffff0bff32ffff0bff32ffff0bff3cff2280ff0580ffff0bff32ffff02ff2affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff5fffff01ff02ffff03ffff09ff82011fff3880ffff01ff02ffff03ffff09ffff18ff82059f80ff3c80ffff01ff02ffff03ffff20ff81bf80ffff01ff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff82019fffff04ff82017fff80808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff0180ffff01ff02ffff03ffff09ff82011fff2c80ffff01ff02ffff03ffff20ff82017f80ffff01ff04ffff04ff24ffff04ffff0eff10ffff02ff2effff04ff02ffff04ff82019fff8080808080ff808080ffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ffff02ff0bffff04ff17ffff04ff2fffff04ff82019fff8080808080ff8080808080808080808080ffff01ff088080ff0180ffff01ff02ffff03ffff09ff82011fff2480ffff01ff02ffff03ffff20ffff02ffff03ffff09ffff0122ffff0dff82029f8080ffff01ff02ffff03ffff09ffff0cff82029fff80ffff010280ff1080ffff01ff0101ff8080ff0180ff8080ff018080ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff8080808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff018080ff018080ff0180ffff01ff02ff3affff04ff02ffff04ff05ffff04ff0bffff04ff81bfffff04ffff02ffff03ff82017fffff0182017fffff01ff02ff0bffff04ff17ffff04ff2fffff01ff808080808080ff0180ff8080808080808080ff0180ff018080ffff04ffff01a0c5abea79afaa001b5427dfa0c8cf42ca6f38f5841b78f9b3c252733eb2de2726ffff04ffff0180ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff04ff82013fffff04ff80ffff04ffff02ffff03ffff22ff82013fffff20ffff09ff82013fff2f808080ffff01ff04ffff04ff10ffff04ffff0bffff02ff2effff04ff02ffff04ff09ffff04ff8205bfffff04ffff02ff3effff04ff02ffff04ffff04ff09ffff04ff82013fff1d8080ff80808080ff808080808080ff1580ff808080ffff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ffff01ff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ff0180ff80808080ffff01ff04ff2fffff01ff80ff80808080ff0180ffff04ffff01ffffff3f02ff04ff0101ffff822710ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff2cff1480ffff0bff2affff0bff2affff0bff2cff3c80ff0980ffff0bff2aff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ff17ffff01ff04ffff04ff10ffff04ffff0bff81a7ffff02ff3effff04ff02ffff04ffff04ff2fffff04ffff04ff05ffff04ffff05ffff14ffff12ff47ff0b80ff128080ffff04ffff04ff05ff8080ff80808080ff808080ff8080808080ff808080ffff02ff16ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fff8080808080808080ff8080ff0180ffff0bff2affff0bff2cff1880ffff0bff2affff0bff2affff0bff2cff3c80ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff3effff04ff02ffff04ff09ff80808080ffff02ff3effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa075690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8da0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01a0c05f74b4f7e8b79dbb23118d7bcdebcadbaddac46824acebe455481c3ec850daffff04ffff0180ff0180808080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0815cec38feefbc2669d2eab272deb4badc17bc42a0f1cecbf1f5cf8c0219d9b7cdad195b9588291642db49da17b99b6eff018080ff018080808080ff018080808080ff01808080', + 'solution': '0xffffa02f1c4f4568c420033fb690c134ed3ed3d8d9fa3bdb75f1044d51789b59ea3a1dff0180ff01ffffffff80ffff01ffff81f6ff80ff80ff8080ffff33ffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6ff01ffffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6ffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6808080ff8080808080' + }, { + 'coin': { + 'amount': 9734999999, + 'parent_coin_info': '0x265cee97bfc72cc1c41692c9462d098009f5bcade81202cfbacf717a988b8667', + 'puzzle_hash': '0x7b0628c573b77df18bf858b6111be39e25e040f4fdb74c74702dfd94b1bd7fbb' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0aa1fdb303fb4e59c8082380e3462a0a4ff3f66ccfb5c40b33b6a13706206b1796f2a32c035a452a26d9926fccb0e3246ff018080', + 'solution': '0xff80ffff01ffff33ffa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ff0180ffff33ffa0e520db6f3cab1c1a26f84f6bb19f44c103a3609a2b552ed1e2647dbf600fd160ff85023474bb7e80ffff34ff840fcb944080ffff3cffa0a8520fb03d767496573596438ba3e9414cc845b1d2ab26c159ab64be397dd7ba80ffff3dffa05751070a5bfeabb3f71640bacfa81ea2275c36a25a60bb4381ef598cb56bca578080ff8080' + }, { + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x2f1c4f4568c420033fb690c134ed3ed3d8d9fa3bdb75f1044d51789b59ea3a1d', + 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' + }, + 'puzzle_reveal': '0xff02ffff01ff04ffff04ff04ffff04ff05ffff04ff0bff80808080ffff04ffff04ff0affff04ffff02ff0effff04ff02ffff04ffff04ff05ffff04ff0bffff04ff17ff80808080ff80808080ff808080ff808080ffff04ffff01ff33ff3cff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff0effff04ff02ffff04ff09ff80808080ffff02ff0effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080', + 'solution': '0xffa0d41dce69252d14db9a19eb0fcbd0e014d416245460b76a9fe4e7a8030e1bb4c6ff01ff8080' + }] } ``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/chialisp-and-typescript.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/chialisp-and-typescript.md index f8ada3518b..89527d0016 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/chialisp-and-typescript.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/chialisp-and-typescript.md @@ -19,10 +19,10 @@ You can do RPC calls with pretty much any language, but to create larger applica This guide is meant to be an example that will give you some basic experience. We will be using Node.js with TypeScript to create a signature enforced coin. We'll use multiple TypeScript libraries for this project, which are open source if you want to see the details on how they work. -- [BLS Signatures](https://npmjs.com/package/@rigidity/bls-signatures) -- [CLVM](https://npmjs.com/package/@rigidity/clvm) -- [RPCs](https://npmjs.com/package/@rigidity/chia) -- [Wallet Helper](https://npmjs.com/package/@rigidity/chia-wallet) +- [BLS Signatures](https://npmjs.com/package/chia-bls) +- [CLVM](https://npmjs.com/package/clvm-lib) +- [RPCs](https://npmjs.com/package/chia-rpc) +- [Wallet Helper](https://npmjs.com/package/chia-wallet-lib) - [DotEnv](https://npmjs.com/package/dotenv) - [BIP39](https://npmjs.com/package/bip39) @@ -176,19 +176,14 @@ If you use Git, you'll want to make sure the `.env` file is added to the `.gitig To not have to mention imports throughout the doc, Our imports will ultimately look like: ```ts -import { - PrivateKey, - fromHex, - AugSchemeMPL, - concatBytes, -} from "@rigidity/bls-signatures"; +import { PrivateKey, fromHex, AugSchemeMPL, concatBytes } from "chia-bls"; import { mnemonicToSeedSync } from "bip39"; import dotenv from "dotenv"; -import { Program } from "@rigidity/clvm"; +import { Program } from "clvm-lib"; import fs from "fs"; import path from "path"; -import { FullNode, formatHex, SpendBundle, toCoinId } from "@rigidity/chia"; -import { KeyStore, StandardWallet } from "@rigidity/chia-wallet"; +import { FullNode, formatHex, SpendBundle, toCoinId } from "chia-rpc"; +import { KeyStore, StandardWallet } from "chia-wallet-lib"; import os from "os"; ``` @@ -291,7 +286,7 @@ You can retrieve your network's Genesis challenge in the terminal with: chia show -s ``` -Testnet10 has the genesis `ae83525ba8d1dd3f09b277de18ca3e43fc0af20d20c4b3e92ef2a48bd291ccb2`. You can see this in `~/.chia/mainnet/config/config.yaml` as well with: +Testnet10 has the genesis `ae83525ba8d1dd3f09b277de18ca3e43fc0af20d20c4b3e92ef2a48bd291ccb2`. You can see this in `~/.chia/mainnet/config/config.yaml` as well with: You can see this in `~/.chia/mainnet/config/config.yaml` as well with: ```bash less ~/.chia/mainnet/config/config.yaml @@ -384,7 +379,7 @@ npm run start ## Crafting a Solution -THe solution for this puzzle consists of a list of conditions. To write Chialisp within JavaScript we can use the `Program.fromSource()` method. We will use a `51` (`CREATE_COIN`) condition delivering the value to our wallet puzzle hash. +The solution for this puzzle consists of a list of conditions. To write Chialisp within JavaScript we can use the `Program.fromSource()` method. We will use a `51` (`CREATE_COIN`) condition delivering the value to our wallet puzzle hash. ```typescript // Calculate an unused address we can send the value to. @@ -455,19 +450,14 @@ Which should produce the following result: Complete Code ```typescript -import { - PrivateKey, - fromHex, - AugSchemeMPL, - concatBytes, -} from "@rigidity/bls-signatures"; +import { PrivateKey, fromHex, AugSchemeMPL, concatBytes } from "chia-bls"; import { mnemonicToSeedSync } from "bip39"; import dotenv from "dotenv"; -import { Program } from "@rigidity/clvm"; +import { Program } from "clvm-lib"; import fs from "fs"; import path from "path"; -import { FullNode, formatHex, SpendBundle, toCoinId } from "@rigidity/chia"; -import { KeyStore, StandardWallet } from "@rigidity/chia-wallet"; +import { FullNode, formatHex, SpendBundle, toCoinId } from "chia-rpc"; +import { KeyStore, StandardWallet } from "chia-wallet-lib"; import os from "os"; dotenv.config(); diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/introduction.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/introduction.md index 0ed1abf190..9e2f12c48d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/introduction.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/introduction.md @@ -264,6 +264,24 @@ Genesis Challenge: ae83525ba8d1dd3f09b277de18ca3e43fc0af20d20c4b3e92ef2a48bd291c Current Blockchain Status: Not Synced. Peak height: 1462514 Time: Wed Aug 31 2022 13:49:51 EDT Height: 1462514 +Estimated network space: 1.181 TiB +Current difficulty: 708 +Current VDF sub_slot_iters: 70778880 +Total iterations since the start of the blockchain: 3364480016373 + + Height: | Hash: + 1462514 | d799fedae1ef226669f61ad843c5ae7947b42e596664f39fd68fcd299e076916 + 1462513 | 0764f546d9186da788485ce69ebe91969e8cf9495722d9567d67e54e3e3e6ed3 + 1462512 | d6132b015365b7609d0b5179b9daf9e4fd2ad7a9040ec1d13e15df65660cf69e + 1462511 | 8ae2273b4a86fd9af85837c538faa75b572014ac281c6c51ad1eb4ce2a7f8072 + 1462510 | fb392a40b7e3bf38c8628311224b5aaa4a32ecdea403c16ae5d3c48d16b57f47 + 1462509 | 012b1f9213bf823e6b73408019f18ff8330e46b911ba78c1d64fd5019d6cc6d9 + 1462508 | e0f66ca2e00566eee9a3ce4028b6aa11771aa42c9bce34f296d89f42d1a909ce + 1462507 | c900e2fb449db0def030a3c0e6a8bff5d23f6470730236120bcac442b2f1ab0f + 1462506 | 39db9fe7658b545dcf45e8e99797c937b7b93a041485ef28bf9cda2b3529ac0a + 1462505 | ca343b0e985fe9dafb7cba7cee0c1515c6bddd732e2542b8fbd49ac8d90c13f3 Peak height: 355514 + Time: Wed Feb 14 2024 13:49:51 EDT Height: 355514 + Estimated network space: 1.181 TiB Current difficulty: 708 Current VDF sub_slot_iters: 70778880 @@ -288,7 +306,7 @@ Ideally, you'll see within this response a value like `Current Blockchain Status
Testnet Database -For many things you will need a synced full node. Fortunately, an official [testnet database](https://downloads.chia.net/testnet10/) download is available, which can be a much faster option than syncing from scratch. +For many things you will need a synced full node. For many things you will need a synced full node. Fortunately, an official [testnet database](https://downloads.chia.net/testnet10/) download is available, which can be a much faster option than syncing from scratch. Once this file is downloaded, stop your node: @@ -314,7 +332,7 @@ chia show --state ## Getting TXCH -For the rest of this workshop you will need some TXCH (Testnet Chia). You can get some for free from the [official Chia faucet](https://testnet10-faucet.chia.net/). +For the rest of this workshop you will need some TXCH (Testnet Chia). You can get some for free from the [official Chia faucet](https://testnet11-faucet.chia.net/). For this you will need a receive address. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/signatures.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/signatures.md index d0ee8890a2..1400aa87a4 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/signatures.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/signatures.md @@ -350,7 +350,7 @@ To sign the message we will actually need the `coin_id` and the genesis challeng less ~/.chia/mainnet/config/config.yaml ``` -and then search for `genesis_challenge`, picking the one for the appropriate network (such as testnet10). The value will be a hex string such as `ae83525ba8d1dd3f09b277de18ca3e43fc0af20d20c4b3e92ef2a48bd291ccb2` (that is the value for testnet10). +and then search for `genesis_challenge`, picking the one for the appropriate network (such as testnet10). The value will be a hex string such as `ae83525ba8d1dd3f09b277de18ca3e43fc0af20d20c4b3e92ef2a48bd291ccb2` (that is the value for testnet10). ::: The value will be a hex string such as `37a90eb5185a9c4439a91ddc98bbadce7b4feba060d50116a067de66bf236615` (that is the value for testnet11). ::: ## Get Coin Id diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/state.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/state.md index 57a86f85a7..38c48f9ea9 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/state.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/state.md @@ -280,6 +280,12 @@ cdv clsp build message.clsp ## Initial Setup +Install NPM: + +```bash +pip install npm +``` + Install the needed dependencies: ```bash @@ -404,6 +410,13 @@ GENESIS=d25b25b897564035695996922aa0f9ff9d611bd38cd2ecd0d2383a99a70dfc15 EVE_COIN_ID=5fe284bfa91c32fd274179769f5b808c916e5135e603cb292a90e04e5867bd1a ``` +:::info +The hash used in `GENESIS` can be found in your chia environments config.yaml file. +Mainnet Genesis = `ccd5bb71183532bff220ba46c268991a3ff07eb358e8255a65c30a2dce0e5fbb` +Testnet11 Genesis = `37a90eb5185a9c4439a91ddc98bbadce7b4feba060d50116a067de66bf236615` +For the simulator and other testnets please refer to the instances config.yaml `$CHIA_ROOT/config/config.yaml`. +::: + Write the following code to sync the state: ```ts title=index.ts diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-user-guide.md index 4e0d0605bd..dfd8d4a97b 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-user-guide.md @@ -123,7 +123,7 @@ If you get a usage statement, then `cic` (Chia Internal Custody) has been instal --- -## Command Notes +### Command Notes :::info A few notes about the commands in this guide @@ -137,9 +137,12 @@ Most of the commands from this tutorial will _not_ alter the blockchain. This in :::warning warning for windows users -Windows uses different line endings than Linux and MacOS. If you only plan to use Windows for both generating and signing spend bundles, this won't be a problem. +Windows uses different line endings than Linux and MacOS. +If you only plan to use Windows for both generating and signing spend bundles, this won't be a problem. -However, if you plan to generate your spend bundles on Windows and sign them using a Linux HSM, then you will need to modify the line endings before signing. The easiest way to accomplish this is with `dos2unix`. This is not included with Windows, so you will need to download it from [SourceForge](https://sourceforge.net/projects/dos2unix/). +However, if you plan to generate your spend bundles on Windows and sign them using a Linux HSM, then you will need to modify the line endings before signing. +The easiest way to accomplish this is with `dos2unix`. +This is not included with Windows, so you will need to download it from [SourceForge](https://sourceforge.net/projects/dos2unix/). The command to convert your spend bundles is then: @@ -313,9 +316,12 @@ As a result of running this command, `Configuration (awaiting launch).txt` will ::: -In this step, you will run `cic launch_singleton`, which will create the singleton on the blockchain. In order to run this command, you will need to have at least 1 mojo in your wallet to create the singleton. +In this step, you will run `cic launch_singleton`, which will create the singleton on the blockchain. +In order to run this command, you will need to have at least 1 mojo in your wallet to create the singleton. -The `launch_singleton` command also includes a recommended `--fee` flag to specify a blockchain fee in mojos. This fee is completely separate from the actual financing of the singleton, which will occur in a later step. It is also possible to launch the singleton using one wallet and fund it with another -- think of the singleton as a brand new wallet. +The `launch_singleton` command also includes a recommended `--fee` flag to specify a blockchain fee in mojos. +This fee is completely separate from the actual financing of the singleton, which will occur in a later step. +It is also possible to launch the singleton using one wallet and fund it with another -- think of the singleton as a brand new wallet. Aside from the fees, the `launch_singleton` command includes an optional `--configuration` flag to specify the name and location of the configuration file. By default, the command will look in `./Configuration (awaiting launch).txt`. @@ -369,7 +375,8 @@ Congratulations, you have successfully launched the singleton! (You will need to At this point, the singleton should exist on the blockchain. However, it has not yet been funded. For now, let's view it. -Currently your local custody database does not know about the singleton. Therefore, in order to view the singleton, you must first synchronize the localhost with the blockchain by running the `sync` command. +Currently your local custody database does not know about the singleton. +Therefore, in order to view the singleton, you must first synchronize the localhost with the blockchain by running the `sync` command. The first time you run the `sync` command, you need to specify the configuration file, which will then be copied into your config database. @@ -402,7 +409,9 @@ Outstanding events: REKEYS: ``` -To view the configuration, run `cic show` and add the `-c` flag. To view the derivation info, run `cic show` and add the `-d` flag. You can also add both flags. +To view the configuration, run `cic show` and add the `-c` flag. +To view the derivation info, run `cic show` and add the `-d` flag. +You can also add both flags. For example: @@ -620,7 +629,8 @@ This test will run through the complete sequence of withdrawing money from the s This command generates an unsigned spend bundle which requires specific keys. Signers can take this spend bundle to an HSM for signing. -To begin the payment process, use the `cic payment` command. For this example, we'll use the following arguments (see the [CLI reference](/custody-tool#payment "payment command") for all options): +To begin the payment process, use the `cic payment` command. +For this example, we'll use the following arguments (see the [CLI reference](/custody-tool#payment "payment command") for all options): - `-f` : The name of the file in which to save the unsigned spend bundle - `-pks`: The public keys that will be used to sign the withdrawal. Exactly `m` keys must be included. The only keys allowed to sign are those that were originally used in the `derive_root` command @@ -743,7 +753,9 @@ Once you have the signed spend bundle on a synced node with some XCH/TXCH for a cic push_tx -b ./withdrawal.signed -m 10000000 ``` -The withdrawal has now been added to the blockchain. However, the money has not yet reached its final destination. Instead, it will now sit in a "drop coin" (aka escrow) and cannot be withdrawn for at least (`-pc`) seconds, which is built into the singleton and cannot be changed. For this example, we used 1200 seconds for this value. +The withdrawal has now been added to the blockchain. However, the money has not yet reached its final destination. +Instead, it will now sit in a "drop coin" (aka escrow) and cannot be withdrawn for at least (`-pc`) seconds, which is built into the singleton and cannot be changed. +For this example, we used 1200 seconds for this value. #### View the payment's status @@ -784,7 +796,9 @@ As the output of this command shows, there is a new payment outstanding (`PAYMEN - If (`-pc`) seconds have not elapsed since the drop coin's creation, the output will display `(Ready at: )` - If (`-pc`) seconds have elapsed, then the output will say `(Ready)` -In either case, claw backs are allowed until the payment has been completed. (Even if the withdrawal is in "Ready" state, it can still be clawed back. However, because _anyone_ can complete the withdrawal, claw backs should no longer be assumed to be available once the "Ready" state has been reached.) +In either case, claw backs are allowed until the payment has been completed. +(Even if the withdrawal is in "Ready" state, it can still be clawed back. However, because _anyone_ can +complete the withdrawal, claw backs should no longer be assumed to be available once the "Ready" state has been reached.) Note that even when the state is "Ready", the next transaction block will still need to be created before the withdrawal is _actually_ ready. @@ -957,7 +971,8 @@ Outstanding events: REKEYS: ``` -Instead of completing the payment, we'll claw it back. If you want to test this feature, be sure to make the value of `-pc` sufficiently large to give yourself plenty of time to perform the clawback. In this example we still have 17 minutes remaining (`Ready at` minus `Current time` from the above output). +Instead of completing the payment, we'll claw it back. If you want to test this feature, be sure to make the value of `-pc` sufficiently large to give yourself plenty of time to perform the clawback. +In this example we still have 17 minutes remaining (`Ready at` minus `Current time` from the above output). #### Create an unsigned spend bundle for the clawback @@ -1041,7 +1056,8 @@ echo 549614102252741379514039214279174962654364157854486736945228183041555384205 This command should have no output. The signatures are now stored in text files. -Finally, merge the claw back signatures into a signed spend bundle. Note that an arbitrary number of signatures can be passed into this command. We'll use two signatures for this example. +Finally, merge the claw back signatures into a signed spend bundle. +Note that an arbitrary number of signatures can be passed into this command. We'll use two signatures for this example. ```bash hsmmerge ./clawback.unsigned ./clawback_1.sig ./clawback_2.sig > clawback.signed @@ -1241,7 +1257,9 @@ Custody rules successfully added to configuration ::: -Next, run `start_rekey`, which will create an unsigned spend bundle for the rekey. Note that in this command, `-pks` refers to the original keys that must sign to allow the rekey to happen. The configuration file from the `-new` flag contains all of the new info that will be used after the rekey has completed. +Next, run `start_rekey`, which will create an unsigned spend bundle for the rekey. Note that in this command, +`-pks` refers to the original keys that must sign to allow the rekey to happen. +The configuration file from the `-new` flag contains all of the new info that will be used after the rekey has completed. ```bash cic start_rekey -f rekey.unsigned -pks "1.pk,2.pk" -new './Configuration (after rekey).txt' @@ -1300,7 +1318,9 @@ echo 555391688726247518407714092604079246104554134754321333331702549926309406250 echo 5561137392380018602752549597282386367838345256392677171809614780347764174154608487537742644428466353746831639451621586320322685820178179047514852085991565214608652175820480007073564769669494661900487484133333312104972188050976529086895435776 > rekey_2.sig ``` -Finally, merge the rekey signatures into a signed spend bundle. Note that an arbitrary number of signatures can be passed into this command. For this example, we need to use the two signatures we just calculated: +Finally, merge the rekey signatures into a signed spend bundle. +Note that an arbitrary number of signatures can be passed into this command. +For this example, we need to use the two signatures we just calculated: ```bash hsmmerge ./rekey.unsigned ./rekey_1.sig ./rekey_2.sig > rekey.signed @@ -1371,9 +1391,12 @@ As the output of this command shows, there is a new rekey outstanding (`REKEY fr - If (`-rc`) seconds have not elapsed since the drop coin's creation, the output will display `(Ready at: )` - If (`-rc`) seconds have elapsed, then the output will say `(Ready)` -In either case, cancellation/clawback is allowed until the rekey is completed. (Even if the rekey is in "Ready" state, it can still be clawed back. However, because _anyone_ can complete the rekey, claw backs should no longer be assumed to be available once it reaches the "Ready" state.) +In either case, cancellation/clawback is allowed until the rekey is completed. +(Even if the rekey is in "Ready" state, it can still be clawed back. However, because _anyone_ can +complete the rekey, claw backs should no longer be assumed to be available once it reaches the "Ready" state.) -Note that even when the state is "Ready", the next transaction block will still need to be created before the rekey is _actually_ ready. Transaction blocks happen every 52 seconds on average. +Note that even when the state is "Ready", the next transaction block will still need to be created before the rekey is _actually_ ready. +Transaction blocks happen every 52 seconds on average. #### Create a signed spend bundle for the completion diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/prefarm-audit.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/prefarm-audit.md index b3373aaad7..18bdf90209 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/prefarm-audit.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/prefarm-audit.md @@ -7,7 +7,7 @@ Chia Network Inc's prefarm is secured by a complex set of custodial rules. This Other relevant documents: -- [Flow chart](/img/chia-custody-tool.png) to visualize how the custody tool works +- [Flow chart](https://docs.chia.net/img/chia-custody-tool.png) to visualize how the custody tool works - [User guide](/guides/custody-tool-user-guide) to help you get up and running - [CLI reference](/custody-tool) for all custody commands used in this tutorial - [Prefarm Alert Tool](https://github.com/Chia-Network/prefarm-alert) to access the public prefarm config files @@ -76,7 +76,9 @@ xch1jj0gm4ahhlu3ke0r0fx955v8axr6za7rzz6hc0y26lewa7zw6fws5nwvv6 :::info -NOTE: A high level of technical proficiency is needed to understand the details of this manual process for what the cic tool does above. This process is a high-level guide and does not display expected results for each step. The [chia-dev-tools](https://github.com/Chia-Network/chia-dev-tools#install) are needed for this audit. +NOTE: A high level of technical proficiency is needed to understand the details of this manual process for what the cic tool does above. +This process is a high-level guide and does not display expected results for each step. +The [chia-dev-tools](https://github.com/Chia-Network/chia-dev-tools#install) are needed for this audit. ::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-cli-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-cli-guide.md index 4db1e71076..a3a06ee3c0 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-cli-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-cli-guide.md @@ -94,6 +94,12 @@ Coin ID: 0xde53700207e23c74088bd6feaadf39f36248729880ffe112b9420fa27c861d5c ::: +:::note + +This guide will use a CLI command to create a DAO. If preferred, you can also create a DAO with the [create_new_wallet](/wallet-rpc/#create_new_wallet) wallet RPC (see Example 4). + +::: + The command to create a DAO is `chia dao create`. This command contains many options -- see [the documentation](/dao-cli#create) for a complete list. Most of the options are not required. However, we will change several of them because their default values are more appropriate for real-world DAOs. For this example, we will specify the following values: @@ -274,6 +280,12 @@ The DAO now has 5 TXCH in its treasury. But there isn't much point in creating a ### Join a DAO +:::note + +This guide will use a CLI command to join an existing DAO. If preferred, you can also join a DAO with the [create_new_wallet](/wallet-rpc/#create_new_wallet) wallet RPC (see Example 5). + +::: + For this example, we will begin with a wallet that contains 3 TXCH. This will become the wallet for **DAO participant 1**: ```bash diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-known-issues.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-known-issues.md index e79d65ea9c..b8128c96f6 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-known-issues.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-known-issues.md @@ -6,7 +6,9 @@ title: DAO Known Issues import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -This page contains a comprehensive list of known DAO issues. Be sure to read this list carefully before using the DAO primitive. +DAOs are currently under development. Be sure to read this list carefully before using the DAO primitive. + +As of Chia version 2.1.4, the following DAO issues are known to exist: ## Proposal Spam @@ -14,7 +16,10 @@ Under normal circumstances, an attacker can create a malicious proposal to drain However, prior to creating this proposal, the attacker can use proposal spam to improve the chances of the attack's success. -The DAO wallet subscribes to `PROPOSAL` coins by hinting the `TREASURY_ID` in the `memos` field upon the coin's creation. There is a limit on the number of items a `full_node` will return to a wallet based on a subscribed puzzle_hash (including hinted coins): \* `trusted_max_subscribe_response_items`: 500000 \* `max_subscribe_response_items`: 100000 +The DAO wallet subscribes to `PROPOSAL` coins by hinting the `TREASURY_ID` in the `memos` field upon the coin's creation. To release the coins, launch the wallet from `main`, and then run the [release_coins](/dao-cli#release_coins) command. + +- There is a limit on the number of items a `full_node` will return to a wallet based on a subscribed puzzle_hash (including hinted coins): \* `trusted_max_subscribe_response_items`: 500000 \* `max_subscribe_response_items`: 100000 +- Mitigation: This issue only exists in the 2.1.2 release. The attacker can take advantage of this limit by creating multiple coins, each of which contains a hint equal to the `TREASURY_ID`. Eventually a wallet will no longer get any additional coin states for newer coins from a `full_node` via the coin state subscription. This is the "proposal spam" part of the attack. @@ -31,8 +36,8 @@ In the event that such proposals are voted on by users, because the proposals ca The current mitigation to this is that the wallet will filter out any proposals which either don't meet the proposal minimum amount or don't have valid timer coins. It is strongly suggested to use the `show_proposal` command with any proposal that you intend to vote on, and check that it is valid. -## Resync with locked DAO CATs +## Changing a DAO's settings -This issue occurs when you have a balance of locked DAO CATs which have voted on one or more open proposals, then you delete and resync the wallet DB. Once the proposals have closed, attempting to unlock the coins from voting mode will fail due to missing lineage proofs for the locked coins. +Because each proposal is voted on and enacted independently, it is possible to have a situation where a proposal to change one or more of the DAO's settings passes while another proposal is active. In this case, the active proposal will take on the _new_ rules imposed by the proposal to change the DAO's settings. This situation could cause the existing proposal to fail, even if it would have passed under the original rules. Other side effects are also possible. -Mitigation: This issue only exists in the 2.1.2 release. It has already been fixed in the `main` branch. To release the coins, launch the wallet from `main`, and then run the [release_coins](/dao-cli#release_coins) command. +Because of this anomaly, a vote for a proposal to change the DAO's settings could affect any of the DAO's other active proposals. Therefore, members are strongly encouraged to examine all open proposals when deciding whether to vote for a proposal to change the DAO's settings. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-user-guide.md index 6dc7a58906..42fc256126 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-user-guide.md @@ -221,7 +221,7 @@ sudo pfctl -sr | grep 8575 ::: -3. (optional) If you are going to use a DataLayer as a Service (DLaaS) plugin, you can add custom headers to `~/.chia/mainnet/config/config.yaml`. For example, you might update the config as follows: +3. (optional) If you are going to use a DataLayer as a Service (DLaaS) plugin, you can add custom headers to `~/.chia/mainnet/config/config.yaml`. For example, you might update the config as follows: For example, you might update the config as follows: ```yaml data_layer: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-intro.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-intro.md index e733cc855a..a441bcc244 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-intro.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-intro.md @@ -126,6 +126,8 @@ values={[ Be sure to replace `` and `` with the actual folder names. +` with the actual folder names. + ```bash Set-Alias -Name chia "C:\Users\\AppData\Local\chia-blockchain\app-\resources\app.asar.unpacked\daemon\chia.exe" ``` @@ -148,7 +150,7 @@ To install Chia from source, follow our [installation guide](https://docs.chia.n ### Switching to testnet -By default, Chia will run on mainnet. To switch to the testnet (recommended) for this guide, see [our testnet instructions](https://docs.chia.net/testnets). +By default, Chia will run on mainnet. By default, Chia will run on mainnet. To switch to the testnet (recommended) for this guide, see [our testnet instructions](https://docs.chia.net/testnets). ## Configuration @@ -243,7 +245,7 @@ Chia Wallet: In order to continue, you'll need to have some TXCH in your wallet. If your total balance is 0, you can obtain 1 TXCH from our faucet. Copy the value of "First wallet address:" from the output of the `chia keys show` command. It will be a long string beginning with "txch". -Open our [testnet faucet page](https://testnet10-faucet.chia.net "Chia's testnet10 faucet link"). Paste your address and click "Submit". +Open our [testnet faucet page](https://testnet10-faucet.chia.net "Chia's testnet10 faucet link"). Paste your address and click "Submit". Paste your address and click "Submit". You'll receive this message: `Accepted. Your request is in the queue and will be processed in the order it was received.` At some point you'll receive 1 TXCH. Depending on how busy the faucet and the testnet are, this could take several minutes. However, you don't need to wait for your coins to arrive before continuing. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/observer-wallet-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/observer-wallet-guide.md new file mode 100644 index 0000000000..8a98cff94c --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/observer-wallet-guide.md @@ -0,0 +1,112 @@ +--- +slug: /guides/observer-wallet-guide +title: Observer Wallet Guide +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +## Intro + +### About + +An observer wallet is a wallet that cannot be used for sending transactions. In other words, it is a read-only wallet. This is a powerful concept for HODLers and farmers alike. + +:::info + +Currently, you need to understand how to use a command line interface (CLI) in order to set up an observer wallet. Eventually, we will make this setup easier for GUI users. + +::: + +Until the introduction of observer wallets, the Chia reference wallet always stored each public/private key pair locally. It was possible to maintain an offline key, for example in order to receive farmer rewards, but checking the balance required using a blockchain explorer. However, as a privacy feature, Chia wallets generate a new address each time they receive money. A blockchain explorer is therefore not always able to provide an accurate view of a wallet's history. + +With an observer wallet, you can view your wallet's history and balance without the risk of funds being stolen by someone who gains access to your computer. + +### Current Status + +The concept of an observer wallet was first introduced to Chia's reference wallet in version 2.4.0. In this version, it is possible to create an observer wallet from a command line, and use it with the GUI. The user experience will improve as more features get added, but for now the core functionality is in place. + +Eventually, we will add the ability to sign transactions using an external signer. + +## Set up + +This guide assumes you have a wallet set up in non-observer mode, and that you want to set up the same wallet in observer mode on a new computer where Chia is also installed. + +The first step is to obtain the wallet's master public key from the original computer. Open a command prompt or terminal window, and enter the following: + +```bash +chia keys show +``` + +Locate your wallet's fingerprint. You will see something like the following: + +```bash +Showing all public keys derived from your master key: + +Label: Testnet11 Small +Fingerprint: +Master public key (m): +Farmer public key (m/12381/8444/0/0): +Pool public key (m/12381/8444/1/0): +First wallet address:
+``` + +Save a copy of the key shown with `Master public key (m):` in a text file. This file must only contain the public key, and it must be on a single line. Copy this file to the computer on which you want to load the wallet in observer mode. + +From your second computer, run the following command to add your wallet in observer mode: + +```bash +chia keys add -f -l "" +``` + +Be sure to enter the actual file path, as well as whatever name you want to call your observer wallet. The output will look something like the following: + +```bash +Added public key with fingerprint +``` + +You may also see a warning such as the following, which can be safely ignored: + +```bash +WARNING: using a farmer address which we might not have the private keys for. We searched the first 50 addresses. Consider overriding with +WARNING: using a pool address which we might not have the private keys for. We searched the first 50 addresses. Consider overriding with +``` + +Your observer wallet has been added. + +## Usage + +If your observer wallet is not immediately displayed in the GUI, click `View` --> `Reload`, and it should appear: + +

+ observer wallet +

+
+ +Your observer wallet should now be displayed. It might have a different icon than the original wallet. Click this wallet to view it: + +

+ observer wallet +

+
+ +You can now send funds to this wallet, and its balance will be updated, just like a non-observer wallet's balance. You can even redirect your farming rewards to this wallet: + +

+ observer wallet +

+
+ +By definition, observer wallets are read-only. To test this, you can try sending funds to another wallet: + +

+ observer wallet +

+
+ +This should result in an error: + +

+ observer wallet +

+
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/seeder-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/seeder-user-guide.md index 1ed4b401ac..a4c14c8a9b 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/seeder-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/seeder-user-guide.md @@ -5,15 +5,15 @@ slug: /guides/seeder-user-guide # Seeder User Guide -The Chia Seeder & Crawler is a tool to keep track of the most reliable nodes on the Chia network. Each instance of the Chia Seeder maintains its own separate list of IP addresses of these nodes. +The Chia Seeder & Crawler is a tool to keep track of the most reliable nodes on the Chia network. Each instance of the Chia Seeder maintains its own separate list of IP addresses of these nodes. Each instance of the Chia Seeder maintains its own separate list of IP addresses of these nodes. -It does so by crawling through the network, periodically revisiting known nodes from its list. If a node is either no longer available, or has exhibited untoward behavior, the Chia Seeder instance removes that node from its list. +It does so by crawling through the network, periodically revisiting known nodes from its list. It does so by crawling through the network, periodically revisiting known nodes from its list. If a node is either no longer available, or has exhibited untoward behavior, the Chia Seeder instance removes that node from its list. -The Chia Seeder runs a mini-DNS server. Anyone can obtain an entry point into Chia’s decentralized and permissionless network via a simple DNS request for reliable node IPs. +The Chia Seeder runs a mini-DNS server. The Chia Seeder runs a mini-DNS server. Anyone can obtain an entry point into Chia’s decentralized and permissionless network via a simple DNS request for reliable node IPs. -The Chia Seeder has very low memory and CPU requirements. +The Chia Seeder has very low memory and CPU requirements. It runs a faux full_node process and does not need its own node. -Chia’s core developers have already been running an instance of the Chia Seeder for some time. You can view the current status of this instance by running: +Chia’s core developers have already been running an instance of the Chia Seeder for some time. You can view the current status of this instance by running: You can view the current status of this instance by running: ```bash # IPv4 @@ -33,7 +33,7 @@ Features: ## Expectations for Chia Seeder operators -The Chia network core developers endeavor to minimize the level of trust in the DNS servers associated with a Chia Seeder. In this regard, it is expected for each Chia Seeder to be run by an individual or organization recognized as well-intentioned within the Chia community. +The Chia network core developers endeavor to minimize the level of trust in the DNS servers associated with a Chia Seeder. In this regard, it is expected for each Chia Seeder to be run by an individual or organization recognized as well-intentioned within the Chia community. In this regard, it is expected for each Chia Seeder to be run by an individual or organization recognized as well-intentioned within the Chia community. This entails following good host security practices, maintaining control of the underlying infrastructure, and not transferring control of the Chia Seeder they operate. @@ -50,6 +50,7 @@ There are additional operation considerations for inclusion in the `initial-conf ```bash $ sh install.sh $ . ./activate +$ chia init ./activate $ chia init ``` @@ -57,11 +58,11 @@ You most certainly will want to specify your own configuration of a domain name ## Special instructions on Ubuntu -On Ubuntu, it is possible that systemd-resolved already binds port 53. The Chia Seeder's built-in DNS server is run on the same port, and systemd-resolved takes precedence by default. +On Ubuntu, it is possible that systemd-resolved already binds port 53. On Ubuntu, it is possible that systemd-resolved already binds port 53. The Chia Seeder's built-in DNS server is run on the same port, and systemd-resolved takes precedence by default. Special instructions to free port 53 are provided here (points #2 and #3): https://github.com/team-exor/generic-seeder#exclamation-special-instructions-for-ubuntu-users-exclamation -This amounts to editing `/etc/systemd/resolved.conf` so as to disable binding of systemd-resolved to port 53 by setting `DNSStubListener=no`, or, alternatively, entirely disabling the systemd-resolved service. Note that you will likely need to add a nameserver in '/etc/resolv.conf'. +This amounts to editing `/etc/systemd/resolved.conf` so as to disable binding of systemd-resolved to port 53 by setting `DNSStubListener=no`, or, alternatively, entirely disabling the systemd-resolved service. Note that you will likely need to add a nameserver in '/etc/resolv.conf'. Note that you will likely need to add a nameserver in '/etc/resolv.conf'. ```bash # Example resolv.conf @@ -88,12 +89,14 @@ For a local DNS server setup, you will need control of a top-level domain (TLD) :::note Note that while it may be possible to use an existing domain, it is recommended to register a new domain name to specifically run the Chia Seeder address. ::: +::: -Proceed by logging into your domain registrar and navigating to the section pertaining to managing DNS records for your domain. Next, click or activate the button or mechanism for creating a new DNS record. Finally, create new type "A" and "AAAA" DNS record(s) for `vps.example.com`, which point at the ipv4 and ipv6 address(s) of the server running the seeder along with another new DNS record of type "NS" at `my-chia-seeder.example.com` with the nameserver set to the servers hostname, `vps.example.com`. +Proceed by logging into your domain registrar and navigating to the section pertaining to managing DNS records for your domain. Next, click or activate the button or mechanism for creating a new DNS record. Proceed by logging into your domain registrar and navigating to the section pertaining to managing DNS records for your domain. Next, click or activate the button or mechanism for creating a new DNS record. Finally, create new type "A" and "AAAA" DNS record(s) for `vps.example.com`, which point at the ipv4 and ipv6 address(s) of the server running the seeder along with another new DNS record of type "NS" at `my-chia-seeder.example.com` with the nameserver set to the servers hostname, `vps.example.com`. :::note Note that these names are examples, and as long as the "NS" record points at the hostname of the server, the seeder will work. ::: +::: You can check that this is the case by running the following command (please ensure that you have `dig` on your system by installing the `dnsutils` or `bind9-dnsutils` package; for instance, on Ubuntu, `$ sudo apt install dnsutils` or `$ sudo apt install bind9-dnsutils`): @@ -110,21 +113,21 @@ my-chia-seeder.example.com. 86400 IN NS vps.example.com For another example on how to set-up "A" and "NS" records for your domain using DigitalOcean, please refer to the following video, from 9:40 onward: https://www.youtube.com/watch?v=DsaxbwwVEXk&t=580s -For AWS Route 53 - in the hosted zone you want to use e.g. `example.com` add a "NS"/nameserver record with the `Record name` of `my-chia-seeder` and a value of `vps.example.com`. As of January 2023, the Route 53 web user interface requires you first enter text into the `Record name` field as the Record type of MX will otherwise be greyed out in the pulldown. Then you will create both an A and a AAAA record for `vps.example.com` that corresponds to your vps's IP addresses. +For AWS Route 53 - in the hosted zone you want to use e.g. `example.com` add a "NS"/nameserver record with the `Record name` of `my-chia-seeder` and a value of `vps.example.com`. As of January 2023, the Route 53 web user interface requires you first enter text into the `Record name` field as the Record type of MX will otherwise be greyed out in the pulldown. Then you will create both an A and a AAAA record for `vps.example.com` that corresponds to your vps's IP addresses. As of January 2023, the Route 53 web user interface requires you first enter text into the `Record name` field as the Record type of MX will otherwise be greyed out in the pulldown. Then you will create both an A and a AAAA record for `vps.example.com` that corresponds to your vps's IP addresses. -In `config.yaml` the `domain_name` is `my-chia-seeder.example.com.` and the `nameserver` is `vps.example.com.`. Note the trailing periods. The main thing to change in `soa` is adding a correct contact email in `rname` and optionally changing the `serial_number`. +In `config.yaml` the `domain_name` is `my-chia-seeder.example.com.` and the `nameserver` is `vps.example.com.`. Note the trailing periods. The main thing to change in `soa` is adding a correct contact email in `rname` and optionally changing the `serial_number`. Note the trailing periods. The main thing to change in `soa` is adding a correct contact email in `rname` and optionally changing the `serial_number`. ## Running ```bash -$ . ./activate +$ . $ . ./activate $ chia start seeder ``` will run both a crawler and a DNS server. Alternatively, ```bash -$ . ./activate +$ . $ . ./activate $ chia start crawler ``` @@ -145,12 +148,12 @@ If you tail the logs as you start up the node you should see the node connect an 2023-01-14T15:19:31.010 full_node chia.full_node.full_node: INFO Received 32 peers from DNS seeder, using rdtype = AAAA. ``` -Sometimes dns takes a moment so seeing some initial flakiness here is not cause for concern. Just stop again, delete `peers.dat` and try the test again. +Sometimes dns takes a moment so seeing some initial flakiness here is not cause for concern. Sometimes dns takes a moment so seeing some initial flakiness here is not cause for concern. Just stop again, delete `peers.dat` and try the test again. ## Stopping ```bash -$ . ./activate +$ . $ . ./activate $ chia stop -d all ``` @@ -158,12 +161,12 @@ $ chia stop -d all There are a couple of criteria we all look for when adding a seeder to the initial config file. -You must have an ICANN registered domain name. Your seeder host must support IPv6 and IPv4. +You must have an ICANN registered domain name. You must have an ICANN registered domain name. Your seeder host must support IPv6 and IPv4. -We ask that you commit to a monthly uptime of 99.9% which is available enough to be reliable but also leaves flexibility to not need to run a cluster and gives you time for a reboot once in a while to keep up with things like security patches. We will be monitoring all of the seeders listed in the most recent version of `initial-config.yaml`. We highly recommend that you enable monitoring of your seeder as well. We are heavy users of [Uptime Robot](https://uptimerobot.com/) but anything similar will do. +We ask that you commit to a monthly uptime of 99.9% which is available enough to be reliable but also leaves flexibility to not need to run a cluster and gives you time for a reboot once in a while to keep up with things like security patches. We will be monitoring all of the seeders listed in the most recent version of `initial-config.yaml`. We highly recommend that you enable monitoring of your seeder as well. We are heavy users of [Uptime Robot](https://uptimerobot.com/) but anything similar will do. We will be monitoring all of the seeders listed in the most recent version of `initial-config.yaml`. We highly recommend that you enable monitoring of your seeder as well. We are heavy users of [Uptime Robot](https://uptimerobot.com/) but anything similar will do. -Being a known community member - the better you're known (pseudonymously is fine) - the more likely you are to be added. You should have an account on [Keybase](https://keybase.io/) and we will need to know your Keybase handle, as you will be added to a seeder operator's private channel. +Being a known community member - the better you're known (pseudonymously is fine) - the more likely you are to be added. Being a known community member - the better you're known (pseudonymously is fine) - the more likely you are to be added. You should have an account on [Keybase](https://keybase.io/) and we will need to know your Keybase handle, as you will be added to a seeder operator's private channel. -The final criteria is geographical dispersion. If you are hosting in a region where we don't have a seeder, you are more likely to be added. We will want to know what country (and region if it's a large country e.g. North West US) - generally - your seeder will reside in to facilitate this. +The final criteria is geographical dispersion. The final criteria is geographical dispersion. If you are hosting in a region where we don't have a seeder, you are more likely to be added. We will want to know what country (and region if it's a large country e.g. North West US) - generally - your seeder will reside in to facilitate this. We will want to know what country (and region if it's a large country e.g. North West US) - generally - your seeder will reside in to facilitate this. The easiest way to propose being added is to open a pull request for [initial-config.yaml](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/util/initial-config.yaml) and include the information required from the four points above. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/simulator-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/simulator-user-guide.md index 10f52faeef..db6aa5a210 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/simulator-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/simulator-user-guide.md @@ -12,7 +12,7 @@ This document will guide you through the process of setting up Chia's Simulator. - [Simulator CLI Reference](/simulator-cli) :::note -It is possible to run the simulator and either Chia's testnet or mainnet simultaneously. This is because the simulator will use its own ports and directories. +It is possible to run the simulator and either Chia's testnet or mainnet simultaneously. This is because the simulator will use its own ports and directories. ::: This is because the simulator will use its own ports and directories. ::: --- @@ -24,7 +24,7 @@ The simulator is included in the `chia-blockchain` GitHub repository (the same r After you have installed from source and have activated your virtual environment (you should see `(venv)` on the left side of your command prompt), you are all set to install the simulator. :::warning -If you installed Chia from the binary installation file, you cannot use this installation to run the simulator. Instead, follow the instructions linked above to create a new installation from source, then return to this guide. +If you installed Chia from the binary installation file, you cannot use this installation to run the simulator. Instead, follow the instructions linked above to create a new installation from source, then return to this guide. ::: Instead, follow the instructions linked above to create a new installation from source, then return to this guide. ::: ## Setup instructions @@ -89,7 +89,7 @@ Make sure your CHIA_ROOT Environment Variable is set to: C:\Users\\.chia\s ### Configure the environment -Now that you have created the simulator, you can set the `CHIA_ROOT` environment variable to point to the simulator's installation directory. This will enable you to run the simulator from outside of `chia-blockchain`: +Now that you have created the simulator, you can set the `CHIA_ROOT` environment variable to point to the simulator's installation directory. This will enable you to run the simulator from outside of `chia-blockchain`: This will enable you to run the simulator from outside of `chia-blockchain`: :::note -By setting the `CHIA_ROOT` path to the simulator in the current shell window (rather than globally), this enables you to run the simulator in tandem with a full node running on either the testnet or on mainnet. This is because the simulator uses different ports than a normal full node. +By setting the `CHIA_ROOT` path to the simulator in the current shell window (rather than globally), this enables you to run the simulator in tandem with a full node running on either the testnet or on mainnet. This is because the simulator uses different ports than a normal full node. ::: This is because the simulator uses different ports than a normal full node. ::: ## Usage instructions @@ -137,6 +137,7 @@ This command is the equivalent of `chia start node` on testnet and mainnet. :::note You will need to have your `CHIA_ROOT` set before using this command, otherwise it will try to connect to your mainnet or testnet node. ::: +::: Run the following command to start the wallet: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/custom-puzzle-lock.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/custom-puzzle-lock.md index 6aea346065..dfcf04b844 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/custom-puzzle-lock.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/custom-puzzle-lock.md @@ -98,7 +98,7 @@ A solution to this puzzle then needs to contain the compiled puzzle we want to h **Example solution for the password-locked coin:** ```chialisp -((a (q 2 (i (= (sha256 5) (q . 0x2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824)) (q 4 (c 2 (c 11 (c 23 ()))) ()) (q 8)) 1) (c (q . 51) 1))) +((a (q 2 (i (= (sha256 5) (q . 0x2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824)) (q 4 (c 2 (c 11 (c 23 ()))) ()) (q 8)) 1) (c (q . 51) 1))) 0x2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824)) (q 4 (c 2 (c 11 (c 23 ()))) ()) (q 8)) 1) (c (q . 51) 1))) ``` The resulting hash for this example puzzle is again `0x4843c869bba5f65aa1e806cd372dae5668ca3b69640d067e86837ca96b324e71`. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-cli.md index 90ac9a7c8c..4237631503 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-cli.md @@ -381,7 +381,7 @@ Wallet ID 4 type COLOURED_COIN CAT King Cole (Asset ID: 1121996b75cce3c746369ace ## Create an expiring Offer (RPC) -In this example, we will offer 0.1 CATs (`Launcher ID: 91aa...004r`) in exchange for 1 TXCH (`Wallet ID: 1`). In addition, we will add an expiry timestamp so that this Offer will expire on Jan. 1, 2024. This is accomplished with the `max_time` flag: +In this example, we will offer 0.1 CATs (`Launcher ID: 91aa...004r`) in exchange for 1 TXCH (`Wallet ID: 1`). In addition, we will add an expiry timestamp so that this Offer will expire on Jan. 1, 2024: In addition, we will add an expiry timestamp so that this Offer will expire on Jan. 1, 2024. This is accomplished with the `max_time` flag: ```bash chia rpc wallet create_offer_for_ids '{"offer":{"1":1000000000000,"91aa49303fd325cf8029cc0ee5e19ac78ec33d641d63b50d0ba859309a73004d":-100},"fee":10000000,"driver_dict":{},"validate_only":false, "max_time": 1704070800}' diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-gui.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-gui.md index 0b4a7f18b5..ddb08929f7 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-gui.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-gui.md @@ -1,5 +1,5 @@ --- -slug: /guides/offers-gui-tutorial-old +slug: /guides/offers-gui-tutorial title: Offers - GUI --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/verifiable-credentials-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/verifiable-credentials-guide.md index 93d8188a35..345e26fb80 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/verifiable-credentials-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/verifiable-credentials-guide.md @@ -20,18 +20,18 @@ For additional resources, see the following: :::warning -The commands in this guide are only examples. Be sure to replace the listed values with values from your local system. +The commands in this guide are only examples. The commands in this guide are only examples. Be sure to replace the listed values with values from your local system. -This guide was creating using testnet10. The example commands use a fee of 100 million mojos, which will be rather high for mainnet usage. If running on mainnet, be sure to adjust your fees accordingly. +This guide was creating using testnet11. This guide was creating using testnet10. The example commands use a fee of 100 million mojos, which will be rather high for mainnet usage. If running on mainnet, be sure to adjust your fees accordingly. If running on mainnet, be sure to adjust your fees accordingly. ::: ## Definitions - **Decentralized Identifier (DID)** -- A decentralized way to represent an identity of an organization, a person, or any other entity -- **Verifiable Credential (VC)** -- Allows someone or something to prove that a subject belongs to a certain category or categories, such as being a US citizen. One type of VC is issued by a Know Your Customer (KYC) provider, who must perform this verification. +- **Verifiable Credential (VC)** -- Allows someone or something to prove that a subject belongs to a certain category or categories, such as being a US citizen. One type of VC is issued by a Know Your Customer (KYC) provider, who must perform this verification. One type of VC is issued by a Know Your Customer (KYC) provider, who must perform this verification. - In Chia terminology, VCs depend on DIDs. In other words, a DID is required in order to mint a VC on Chia's blockchain. + In Chia terminology, VCs depend on DIDs. In Chia terminology, VCs depend on DIDs. In other words, a DID is required in order to mint a VC on Chia's blockchain. - **Proofs** -- Key-value pairs that are attached to a VC @@ -46,11 +46,11 @@ In order to mint a VC, you will need to have: - One mojo to create a VC singleton - Sufficient funds to cover blockchain fees, the amount of which depend on how busy the blockchain is at any moment -You are recommended to test minting VCs on the testnet prior to minting them on mainnet. If you are unsure of how to configure your wallet to use the testnet, see our [guide](https://docs.chia.net/guides/chialisp-testnet-setup). +You are recommended to test minting VCs on the testnet prior to minting them on mainnet. You are recommended to test minting VCs on the testnet prior to minting them on mainnet. If you are unsure of how to configure your wallet to use the testnet, see our [guide](https://docs.chia.net/guides/chialisp-testnet-setup). We also have faucets available if you don't have sufficient funds to get started: -- [testnet](https://testnet10-faucet.chia.net/) +- [testnet](https://testnet11-faucet.chia.net/) - [mainnet](https://faucet.chia.net/) ### Entities Involved @@ -60,7 +60,7 @@ VC issuance and usage involves at least two entities: 1. Credential subject / holder -- the individual or entity who has applied for a VC (aka the _subject_) or currently holds a VC (aka the _holder_) 2. Proof provider / credential issuer -- the entity that creates and signs the VC, thus asserting the claims about the holder's identity, attributes, or qualifications, and provides a proof for those claims in a credential that is issued to the holder -To test issuing, minting, and revoking VCs, you will need to create separate wallets to represent both of these entities. The two wallets can coexist on the same computer. +To test issuing, minting, and revoking VCs, you will need to create separate wallets to represent both of these entities. The two wallets can coexist on the same computer. The two wallets can coexist on the same computer. :::info note @@ -74,20 +74,20 @@ For this guide, the Verifier is the blockchain itself. ### DID Creation -The proof provider **must** have a DID in order to mint a VC. In order to create a DID, run the following command from a terminal window or command prompt: +The proof provider **must** have a DID in order to mint a VC. The proof provider **must** have a DID in order to mint a VC. In order to create a DID, run the following command from a terminal window or command prompt: ```bash chia wallet did create -m 0.0001 ``` -The response will include the ID of the newly created DID (it will begin with `did:chia:`). Save your local DID ID for later (it will be different from the one displayed here): +The response will include the ID of the newly created DID (it will begin with `did:chia:`). Save your local DID ID for later (it will be different from the one displayed here): Save your local DID ID for later (it will be different from the one displayed here): ```bash Successfully created a DID wallet with name None and id 2 on key 1725104286 Successfully created a DID did:chia:1rnvmwp3wmglslk942mwsrmf7dlkluytyna8mgewel44h4ne3nd9slhtddg in the newly created DID wallet ``` -The DID will be created with an on-chain transaction. After this transaction has been confirmed, you can view your DID by running `chia wallet show`: +The DID will be created with an on-chain transaction. The DID will be created with an on-chain transaction. After this transaction has been confirmed, you can view your DID by running `chia wallet show`: ```bash chia wallet show @@ -124,7 +124,7 @@ This section will show you how to mint, transfer, and revoke a VC using Chia's ` ### Create proofs -First, you must add proofs to the local database. To do this, run the [add_proof_reveal](/vc-cli#add_proof_reveal) command. You can add multiple proofs by reusing the `proof` parameter. For example: +First, you must add proofs to the local database. First, you must add proofs to the local database. To do this, run the [add_proof_reveal](/vc-cli#add_proof_reveal) command. You can add multiple proofs by reusing the `proof` parameter. For example: You can add multiple proofs by reusing the `proof` parameter. For example: ```bash chia wallet vcs add_proof_reveal --proof test_proof1 --proof test_proof2 @@ -152,7 +152,7 @@ Be sure to note your own root hash, as you will need it when minting a VC. :::warning important -When using the CLI to add proofs, the value of each proof will be `1`. This is not configurable in the CLI. If you need to use different values, see the [RPC guide](#rpc-guide) instead. +When using the CLI to add proofs, the value of each proof will be `1`. This is not configurable in the CLI. If you need to use different values, see the [RPC guide](#rpc-guide) instead. This is not configurable in the CLI. If you need to use different values, see the [RPC guide](#rpc-guide) instead. ::: @@ -197,9 +197,9 @@ To address: txch1wrr3hew9nr8ukenv3nwq0fg78h4uh5pm9shyqjl4rmfz9nuqcyxqcy8lth Created at: 2023-06-23 12:34:13 ``` -By default, the VC will be minted to the same wallet that runs this command. However, you can also use the `--target-address` parameter to mint the VC to a different address. +By default, the VC will be minted to the same wallet that runs this command. By default, the VC will be minted to the same wallet that runs this command. However, you can also use the `--target-address` parameter to mint the VC to a different address. -When a VC is first minted, it will not contain any proofs. You can verify this by running the `get` command: +When a VC is first minted, it will not contain any proofs. You can verify this by running the `get` command: You can verify this by running the `get` command: ```bash chia wallet vcs get @@ -215,13 +215,13 @@ Coin ID: 8942dc321387287084a92e6451a01505e6771df81daa86937679eb1ef67abb4a Inner Address: txch1wrr3hew9nr8ukenv3nwq0fg78h4uh5pm9shyqjl4rmfz9nuqcyxqcy8lth ``` -This command shows the `Launcher ID` (the VC's ID), which you will need for the next command. In addition, the `Coin ID` will be required in case the proofs need to be revoked later. +This command shows the `Launcher ID` (the VC's ID), which you will need for the next command. In addition, the `Coin ID` will be required in case the proofs need to be revoked later. In addition, the `Coin ID` will be required in case the proofs need to be revoked later. -Previously, you added your desired proofs to the local database and calculated the root hash. The next step is to add this root hash to the VC, and simultaneously send it to the new holder. This is accomplished by spending the VC. +Previously, you added your desired proofs to the local database and calculated the root hash. Previously, you added your desired proofs to the local database and calculated the root hash. The next step is to add this root hash to the VC, and simultaneously send it to the new holder. This is accomplished by spending the VC. This is accomplished by spending the VC. ### Add proofs to a VC -Use the [update_proofs](/vc-cli#update_proofs) command to add proofs to a VC. This command must be run from the proof provider's wallet (the wallet that contains the DID used for minting). +Use the [update_proofs](/vc-cli#update_proofs) command to add proofs to a VC. This command must be run from the proof provider's wallet (the wallet that contains the DID used for minting). This command must be run from the proof provider's wallet (the wallet that contains the DID used for minting). The `--new-proof-hash` parameter is required; this hash was included in the response from running the `add_proof_reveal` command. @@ -258,7 +258,7 @@ To address: txch1ehkl33dypc7mg820c7j94zfg8pz5j5lqtx7253nmxft52ryvzw8stx7czc Created at: 2023-06-23 12:48:15 ``` -After this transaction has been confirmed on the blockchain, the new **credential holder** can confirm that the proofs are included. First, the credential holder needs to run the same command as the proof provider to add the proofs to the local database. For example: +After this transaction has been confirmed on the blockchain, the new **credential holder** can confirm that the proofs are included. First, the credential holder needs to run the same command as the proof provider to add the proofs to the local database. For example: First, the credential holder needs to run the same command as the proof provider to add the proofs to the local database. For example: ```bash chia wallet vcs add_proof_reveal --proof test_proof1 --proof test_proof2 @@ -276,7 +276,7 @@ Next, the credential holder can run the [get](/vc-cli#get) command: chia wallet vcs get ``` -In this case, one VC is shown, along with the proof hash and both proofs. If the proofs were not manually added to the local database, they would not show in this command, and the GUI would show the VC as invalid. +In this case, one VC is shown, along with the proof hash and both proofs. In this case, one VC is shown, along with the proof hash and both proofs. If the proofs were not manually added to the local database, they would not show in this command, and the GUI would show the VC as invalid. ```bash Proofs: @@ -292,13 +292,13 @@ Proof Hash: f063e22557705b14425b8fca60018796b4364eb6354f45d0b99431a71d3043e5 ### Revoke a VC -Typically, the proof provider only needs to mint a VC, add proofs, and transfer the VC to the new holder. However, at some point, a holder's proofs may change. For example, a holder might have originally proven that they were not a US citizen, and then they later became a US citizen. +Typically, the proof provider only needs to mint a VC, add proofs, and transfer the VC to the new holder. However, at some point, a holder's proofs may change. For example, a holder might have originally proven that they were not a US citizen, and then they later became a US citizen. However, at some point, a holder's proofs may change. For example, a holder might have originally proven that they were not a US citizen, and then they later became a US citizen. -In cases such as this, the proof provider needs to _revoke_ the credentials, ie to remove all proofs from a VC. (The holder will continue to hold the VC, but it will no longer contain any proofs.) We don't allow the proof provider to take back the VC itself because it is possible for it to custody other assets, though we don't support this yet. +In cases such as this, the proof provider needs to _revoke_ the credentials, ie to remove all proofs from a VC. (The holder will continue to hold the VC, but it will no longer contain any proofs.) We don't allow the proof provider to take back the VC itself because it is possible for it to custody other assets, though we don't support this yet. (The holder will continue to hold the VC, but it will no longer contain any proofs.) We don't allow the proof provider to take back the VC itself because it is possible for it to custody other assets, though we don't support this yet. The only wallet that is allowed to revoke credentials is the proof provider's (the wallet that contains the DID used to mint the VC). -In order to run the [revoke](/vc-cli#revoke) command, the proof provider will need to know the parent coin ID (the `-p` parameter). Because VCs are singletons, their parent coin IDs will change every time the VC is spent (every time a change is made). +In order to run the [revoke](/vc-cli#revoke) command, the proof provider will need to know the parent coin ID (the `-p` parameter). Because VCs are singletons, their parent coin IDs will change every time the VC is spent (every time a change is made). Because VCs are singletons, their parent coin IDs will change every time the VC is spent (every time a change is made). For testing purposes, the **holder's wallet** can obtain the parent coin ID by running the [vc_get](/vc-rpc#vc_get) RPC. The parent coin ID is the value of the `"parent_coin_info"`. In a production environment, the proof provider will track the VC on-chain and obtain this info immediately prior to revoking the VC. @@ -312,22 +312,23 @@ As a result, the VC will be recreated in the same wallet, but without any proofs ```bash VC successfully revoked! +Proofs successfully updated! Relevant TX records: -Transaction 286cc31575aa167c4b34cbc0a768a162caefb6afea77560db0693934ac3fbf1e +Transaction 76f5ea8475d695e798518cd405070dc22542e31fc85220ff7d2ca7b44852a45b Status: Pending -Amount sent: 1E-12 XCH -To address: txch1ehkl33dypc7mg820c7j94zfg8pz5j5lqtx7253nmxft52ryvzw8stx7czc -Created at: 2023-06-23 13:33:50 +Amount sent: 0 XCH +To address: txch10xjm79zct87gc8ux5vzrhnnt03zjn4ntn5y95w37rsfmp4rxjycquqctuc +Created at: 2023-06-15 10:15:27 -Transaction ae6378e84742ab6abb07df666291093938ec9e06ae8e2b4066d7386d94289ba3 +Transaction f9eebb0520d024aaf4ae176d554c0f806b8d724d21d5da03b5f541fafd69c99f Status: Pending -Amount sent: 0 XCH -To address: txch1mahlm65l8q9frcqcfveekx3a29cd74w6gfajqy05ukz2afrzg03syqkz3p -Created at: 2023-06-23 13:33:50 +Amount sent: 1E-12 XCH +To address: txch1dlyh9rwd9y6clt3pjjs3gh25ck9vlfx7qwqvvru27dmhgtn80z9s2rruam +Created at: 2023-06-15 10:15:28 ``` -After these transactions have been confirmed on-chain, the VC no longer contains any proofs. The holder can verify this: +After these transactions have been confirmed on-chain, the VC no longer contains any proofs. The holder can verify this: The holder can verify this: ```bash chia wallet vcs get @@ -343,7 +344,7 @@ Proofs: ## RPC Guide -This section will show you how to mint, transfer, and revoke a VC using Chia's [wallet RPC](/vc-rpc). The RPC commands will generally give more detailed responses than their CLI equivalents, but the functionality will be mostly the same. +This section will show you how to mint, transfer, and revoke a VC using Chia's `wallet` [CLI commands](/vc-cli). A similar walk-through using RPCs will be presented in the [next section](#rpc-guide). This section will show you how to mint, transfer, and revoke a VC using Chia's [wallet RPC](/vc-rpc). The RPC commands will generally give more detailed responses than their CLI equivalents, but the functionality will be mostly the same.
Note about Windows command escaping @@ -366,7 +367,7 @@ chia rpc wallet vc_get '\"vc_id\": \"13ba084e78475327e41c60df5a108965d7a283f065b ### Create proofs -First, you must add proofs to the local database. To do this, run the [vc_add_proofs](/vc-rpc#vc_add_proofs) command. `"proofs"` is a dictionary of key-value pairs. Unlike the equivalent CLI command, this command allows you to use any string value. +First, you must add proofs to the local database. First, you must add proofs to the local database. To do this, run the [vc_add_proofs](/vc-rpc#vc_add_proofs) command. `"proofs"` is a dictionary of key-value pairs. Unlike the equivalent CLI command, this command allows you to use any string value. `"proofs"` is a dictionary of key-value pairs. Unlike the equivalent CLI command, this command allows you to use any string value. ```json chia rpc wallet vc_add_proofs '{"proofs": {"example_proof_1": "example_value_1", "example_proof_2": "example_value_2"}}' @@ -386,7 +387,7 @@ The next step is to calculate the root hash for the proofs you just added. A VC's proofs are presented as a Merkle tree, the root hash of which is stored on-chain. -When looking up proofs, a hash called a _Proof of Inclusion_ is all that is required to be presented. Any third-party observers of the blockchain won't be able to identify who the VC corresponds to, but the KYC Provider will know this information as the issuer of the VC. +When looking up proofs, a hash called a _Proof of Inclusion_ is all that is required to be presented. When looking up proofs, a hash called a _Proof of Inclusion_ is all that is required to be presented. Any third-party observers of the blockchain won't be able to identify who the VC corresponds to, but the KYC Provider will know this information as the issuer of the VC. In order to construct a Merkle tree from a set of proofs: @@ -500,7 +501,7 @@ console.log( ); ``` -The script will output the proof hash for the proofs your entered. In this example, the output is: +The script will output the proof hash for the proofs your entered. In this example, the output is: In this example, the output is: `96c9597578333c840f895f30af6d40b9f6c0d69100db1a13ae2e26e4c94acdd3` @@ -508,7 +509,7 @@ The script will output the proof hash for the proofs your entered. In this examp :::info -If you want to retrieve your original proofs from a proof hash, run the [vc_get_proofs_for_root](/vc-rpc#vc_get_proofs_for_root) command. For example: +If you want to retrieve your original proofs from a proof hash, run the [vc_get_proofs_for_root](/vc-rpc#vc_get_proofs_for_root) command. For example: For example: ```json chia rpc wallet vc_get_proofs_for_root '{"root": "96c9597578333c840f895f30af6d40b9f6c0d69100db1a13ae2e26e4c94acdd3"}' @@ -532,7 +533,7 @@ Note that this command will only succeed if you have already added the correspon ### Mint a VC -To mint a VC, run the [vc_mint](/vc-rpc#vc_mint) command. The `did_id` parameter is required. This is the DID owned by the minting wallet. You may also optionally pass in a `target_address`, where the VC will be delivered. If this parameter is missing, the VC will be sent to the same wallet that owns the DID: +To mint a VC, run the [vc_mint](/vc-rpc#vc_mint) command. The `did_id` parameter is required. This is the DID owned by the minting wallet. You may also optionally pass in a `target_address`, where the VC will be delivered. If this parameter is missing, the VC will be sent to the same wallet that owns the DID: The `did_id` parameter is required. This is the DID owned by the minting wallet. You may also optionally pass in a `target_address`, where the VC will be delivered. If this parameter is missing, the VC will be sent to the same wallet that owns the DID: ```json chia rpc wallet vc_mint '{"did_id": "did:chia:1rnvmwp3wmglslk942mwsrmf7dlkluytyna8mgewel44h4ne3nd9slhtddg", "target_address": "txch1yfcclacd6sch2w9dz394zjuq7pqnmz5g7mrqac0hjhwpzmyahe9sqetxaz", "fee": 100000000}' @@ -662,21 +663,21 @@ As a result, the spend bundle used to mint the VC will be output: } ``` -When a VC is first minted, it will not contain any proofs. +When a VC is first minted, it will not contain any proofs. You can verify this by running the `get` command: Previously, you added your desired proofs to the local database and calculated the root hash. The next step is to add your root hash to the VC. ### Add proofs to a VC -In Chia, a singleton is a primitive standard that allows a coin to be recreated with different properties when it is spent. Chia VCs are singletons; use the [vc_spend](/vc-rpc#vc_spend) command to spend a VC and recreate it with a new set of proofs. +In Chia, a singleton is a primitive standard that allows a coin to be recreated with different properties when it is spent. In Chia, a singleton is a primitive standard that allows a coin to be recreated with different properties when it is spent. Chia VCs are singletons; use the [vc_spend](/vc-rpc#vc_spend) command to spend a VC and recreate it with a new set of proofs. The `new_proof_hash` parameter is required; this is the root hash you previously obtained. -The `new_puzhash` parameter is typically used, but not required. This parameter allows you to recreate the VC singleton in a different wallet (ie to send the VC to the new holder in the same command that is used to add the proof hash). +The `new_puzhash` parameter is typically used, but not required. This parameter allows you to recreate the VC singleton in a different wallet (ie to send the VC to the new holder in the same command that is used to add the proof hash). This parameter allows you to recreate the VC singleton in a different wallet (ie to send the VC to the new holder in the same command that is used to add the proof hash). :::note -`new_puzhash` requires a _puzzle hash_ and not a wallet address. If you are not sure how to convert a wallet address to a puzzle hash, the [Chia.tt explorer](https://chia.tt/convert) includes a handy puzzle hash converter tool. If you prefer to do this conversion programmatically, use the `decode` command from the [chia-dev-tools](https://github.com/Chia-Network/chia-dev-tools) repository. +`new_puzhash` requires a _puzzle hash_ and not a wallet address. If you are not sure how to convert a wallet address to a puzzle hash, the [Chia.tt explorer](https://chia.tt/convert) includes a handy puzzle hash converter tool. If you prefer to do this conversion programmatically, use the `decode` command from the [chia-dev-tools](https://github.com/Chia-Network/chia-dev-tools) repository. If you are not sure how to convert a wallet address to a puzzle hash, the [Chia.tt explorer](https://chia.tt/convert) includes a handy puzzle hash converter tool. If you prefer to do this conversion programmatically, use the `decode` command from the [chia-dev-tools](https://github.com/Chia-Network/chia-dev-tools) repository. ::: @@ -812,7 +813,7 @@ The response includes the spend bundle used to spend the VC: } ``` -After this transaction has been confirmed on the blockchain, the new **credential holder** can confirm that the proofs are included. First, the credential holder needs to run the same command as the proof provider to add the proofs to the local database. For example: +After this transaction has been confirmed on the blockchain, the new **credential holder** can confirm that the proofs are included. First, the credential holder needs to run the same command as the proof provider to add the proofs to the local database. For example: First, the credential holder needs to run the same command as the proof provider to add the proofs to the local database. For example: ```json chia rpc wallet vc_add_proofs '{"proofs": {"example_proof_1": "example_value_1", "example_proof_2": "example_value_2"}}' @@ -915,9 +916,9 @@ Response: ### Revoke a VC -Typically, the proof provider only needs to mint a VC, add proofs, and transfer the VC to the new holder. However, at some point, a holder's proofs may change. For example, a holder might have originally proven that they were not a US citizen, and then they later became a US citizen. +Typically, the proof provider only needs to mint a VC, add proofs, and transfer the VC to the new holder. However, at some point, a holder's proofs may change. For example, a holder might have originally proven that they were not a US citizen, and then they later became a US citizen. However, at some point, a holder's proofs may change. For example, a holder might have originally proven that they were not a US citizen, and then they later became a US citizen. -In cases such as this, the proof provider needs to _revoke_ the credentials, ie to remove all proofs from a VC. (The holder will continue to hold the VC, but it will no longer contain any proofs.) We don't allow the proof provider to take back the VC itself because it is possible for it to custody other assets, though we don't support this yet. +In cases such as this, the proof provider needs to _revoke_ the credentials, ie to remove all proofs from a VC. (The holder will continue to hold the VC, but it will no longer contain any proofs.) We don't allow the proof provider to take back the VC itself because it is possible for it to custody other assets, though we don't support this yet. (The holder will continue to hold the VC, but it will no longer contain any proofs.) We don't allow the proof provider to take back the VC itself because it is possible for it to custody other assets, though we don't support this yet. The only wallet that is allowed to revoke credentials is the proof provider's (the wallet that contains the DID used to mint the VC). @@ -1083,7 +1084,7 @@ As a result, the VC will be recreated in the same wallet, but without any proofs } ``` -After these transactions have been confirmed on-chain, the VC no longer contains any proofs. The holder can verify this: +After these transactions have been confirmed on-chain, the VC no longer contains any proofs. The holder can verify this: The holder can verify this: ```json chia rpc wallet vc_get_list diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-user-guide.md index 3d66259e9f..f2985d916c 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-user-guide.md @@ -23,7 +23,7 @@ This guide will show you how to use [WalletConnect](https://walletconnect.com/) ## Install the sample dApp -In order to help you get started with WalletConnect, we have created a sample dApp to run Chia wallet RPCs. In this section, we'll install and run the dApp locally. We'll also obtain a link to connect the dApp to a Chia reference wallet. +In order to help you get started with WalletConnect, we have created a sample dApp to run Chia wallet RPCs. In this section, we'll install and run the dApp locally. We'll also obtain a link to connect the dApp to a Chia reference wallet. In this section, we'll install and run the dApp locally. We'll also obtain a link to connect the dApp to a Chia reference wallet. If you would like to connect your Chia reference wallet to a different dApp, then feel free to skip ahead to the [next section](#configure-walletconnect). @@ -59,7 +59,7 @@ Example result: ➜ press h to show help ``` -In this example, the dApp was started locally on port 5173. This is the default port; your dApp may need to use a different port if 5173 is already being used for something else. +In this example, the dApp was started locally on port 5173. In this example, the dApp was started locally on port 5173. This is the default port; your dApp may need to use a different port if 5173 is already being used for something else. 5. Access the sample dApp: @@ -71,7 +71,7 @@ If you see an error message such as `An error as occurred`, the most likely caus ::: -6. The `WalletConnect Example` screen should be displayed. Click `Link Wallet`: +6. The `WalletConnect Example` screen should be displayed. Click `Link Wallet`: Click `Link Wallet`:
Click Connect @@ -146,7 +146,7 @@ If you used this guide to set up the sample dApp, this was the link you obtained
-7. By default, the wallet that is currently synced will be selected (in the red circle below). Click the `Select Keys` dropdown if you want to connect other wallets, then click `CONTINUE`: +7. By default, the wallet that is currently synced will be selected (in the red circle below). By default, the wallet that is currently synced will be selected (in the red circle below). Click the `Select Keys` dropdown if you want to connect other wallets, then click `CONTINUE`:
Dropdown menu @@ -253,7 +253,7 @@ By default, you can only run dApp methods against the wallet key that is current Click the gear icon in the lower left corner of the reference wallet, then click the `INTEGRATION` tab. Two switches will appear at the top of this panel: - `Enable WalletConnect` -- This setting was activated when you enabled WalletConnect earlier in the guide. -- `Key Switching` -- If you activate this setting, your dApp will be able to switch between multiple wallet keys. The selected wallet will need to sync whenever you switch between keys. +- `Key Switching` -- If you activate this setting, your dApp will be able to switch between multiple wallet keys. The selected wallet will need to sync whenever you switch between keys. The selected wallet will need to sync whenever you switch between keys.
Level | Size
(GiB) | Relative
Size | Reward
Increase | Min Spec
Harvester | | :---------- | :--------------- | :------------------ | :-------------------- | :------------------------ | @@ -40,7 +40,7 @@ The right column (Min Spec Harvester) shows the minimum type of computer require - `Pi 4` refers to Chia's minimum spec hardware, the [Raspberry Pi 4](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/) with 4 GB of RAM for CLI farming, or 8 GB for GUI farming. - `Desktop CPU` refers to a power-sipping computer such as the [ASUS Chromebox](https://www.androidcentral.com/best-chromebox). - `Fast CPU` refers to a computer with a higher-end CPU such as an Intel Xeon. -- `GPU` refers to a computer with an Nvidia CUDA-class GPU. The minimum amount of DRAM required is around 600-700 MB for C7 harvesting. For example, a GTX 1060 will work. +- `GPU` refers to a computer with an Nvidia CUDA-class GPU. The minimum amount of DRAM required is around 600-700 MB for C7 harvesting. For example, a GTX 1060 will work. The minimum amount of DRAM required is around 600-700 MB for C7 harvesting. For example, a GTX 1060 will work. :::info @@ -53,15 +53,15 @@ A few things to keep in mind regarding these recommendations: ### TCO spreadsheet -In order to calculate your potential profits from farming at various compression levels, you can use [this spreadsheet](https://docs.google.com/spreadsheets/d/1k6c-OBDtggXqnEfOPdMmq3646puzvOD7dWojwCH2v3c). Simply make a copy of it, then fill in the constants according to your farm. As you will see from the spreadsheet, the compression level you will ultimately choose will depend on a number of factors, such as electricity cost and the size of your farm. +In order to calculate your potential profits from farming at various compression levels, you can use [this spreadsheet](https://docs.google.com/spreadsheets/d/1k6c-OBDtggXqnEfOPdMmq3646puzvOD7dWojwCH2v3c). Simply make a copy of it, then fill in the constants according to your farm. As you will see from the spreadsheet, the compression level you will ultimately choose will depend on a number of factors, such as electricity cost and the size of your farm. Simply make a copy of it, then fill in the constants according to your farm. As you will see from the spreadsheet, the compression level you will ultimately choose will depend on a number of factors, such as electricity cost and the size of your farm. ### Max farm size estimator -The third-party website [xch.farm](https://xch.farm/max-farm-size) has tables for estimating your farm's maximum capacity depending on your CPU/GPU setup. Be sure to pay attention to the `June 2024` column when planning your farm. If your harvester is capable of handling your desired number of plots listed in this column, you should be good to go until 2027 or later. +The third-party website [xch.farm](https://xch.farm/max-farm-size) has tables for estimating your farm's maximum capacity depending on your CPU/GPU setup. Be sure to pay attention to the `June 2024` column when planning your farm. If your harvester is capable of handling your desired number of plots listed in this column, you should be good to go until 2027 or later. Be sure to pay attention to the `June 2024` column when planning your farm. If your harvester is capable of handling your desired number of plots listed in this column, you should be good to go until 2027 or later. ### BladeBit Simulate -The [standalone version of BladeBit](/plotting-software#bladebit-standalone) comes with a simulator that will determine the maximum size of your farm. The basic idea is that you pass in a compressed plot (C1-C9) and it will calculate the maximum number of plots/space your current harvester can handle. +The [standalone version of BladeBit](/plotting-software#bladebit-standalone) comes with a simulator that will determine the maximum size of your farm. The basic idea is that you pass in a compressed plot (C1-C9) and it will calculate the maximum number of plots/space your current harvester can handle. The basic idea is that you pass in a compressed plot (C1-C9) and it will calculate the maximum number of plots/space your current harvester can handle. See the [CLI reference](/plotters-cli#simulate) for a list of options using the simulator. @@ -73,7 +73,7 @@ The simulator's default values are typically fine, other than the filter size. F :::note -It is a good idea to create plots of various sizes (for example, one C3, one C7, and one C9) and then run the simulator against each of them. This will help you to plan for how many harvesters to use, the type of hardware to acquire, etc. +It is a good idea to create plots of various sizes (for example, one C3, one C7, and one C9) and then run the simulator against each of them. This will help you to plan for how many harvesters to use, the type of hardware to acquire, etc. This will help you to plan for how many harvesters to use, the type of hardware to acquire, etc. ::: @@ -91,17 +91,17 @@ The simulator will only work with compressed plots. ::: -The simulator can also be configured to run a real-time simulation against a farm of any given size. This will give you a much better idea of how your system will perform on mainnet. To activate this mode, use the following flags: +The simulator can also be configured to run a real-time simulation against a farm of any given size. This will give you a much better idea of how your system will perform on mainnet. To activate this mode, use the following flags: This will give you a much better idea of how your system will perform on mainnet. To activate this mode, use the following flags: - `--power