zerone
3 weeks ago
25 changed files with 1142 additions and 4 deletions
-
63development/auth.mdx
-
9development/embeddings.mdx
-
57development/engine.mdx
-
29development/function-calling.mdx
-
35development/memory.mdx
-
100development/prisma.mdx
-
77development/prompts.mdx
-
20development/rag.mdx
-
12development/report.mdx
-
9development/reptile.mdx
-
71development/setup.mdx
-
90development/translations.mdx
-
28development/workflow-input.mdx
-
43development/workflows.mdx
-
127introduction.mdx
-
67layer1/candidate.mdx
-
7layer1/explorers.mdx
-
4layer1/introduction.mdx
-
20layer1/staking.mdx
-
91layer1/validators.mdx
-
26layer1/wallet.mdx
-
127layer2/edge.mdx
-
4layer2/introduction.mdx
-
21mint.json
-
7wallet/introduction.mdx
@ -0,0 +1,63 @@ |
|||||
|
--- |
||||
|
title: 认证 |
||||
|
description: 了解 WealthMentor 如何在不同的开发模式和不同的提供者中处理认证。 |
||||
|
icon: "lock" |
||||
|
--- |
||||
|
|
||||
|
# 开发模式下的认证 |
||||
|
|
||||
|
在开发模式下，您的应用程序使用简化版的认证以便于测试和调试。这通常不安全，不应在生产环境中使用。 |
||||
|
|
||||
|
在您的 `.env` 文件中，您可以使用 `NODE_ENV` 变量在开发环境和生产环境之间进行切换。当设置为 "development" 时，应用程序会在开发模式下运行。 |
||||
|
|
||||
|
要使应用程序使用不安全的简化版认证，请将您的 `.env` 文件中的 `NEXTAUTH_SECRET` 变量设置为一个简单的、不安全的值（例如 "changeme"）。 |
||||
|
|
||||
|
## 访问提供者密钥 |
||||
|
|
||||
|
要启用不同类型的 OAuth 认证，您需要从各自的提供者那里获取密钥。以下是获取这些密钥的一般说明： |
||||
|
|
||||
|
<Tabs> |
||||
|
<Tab title="Google"> |
||||
|
|
||||
|
在 Google Cloud Console 中创建一个项目。 |
||||
|
转到 "凭据"，点击 "创建凭据"，然后选择 "OAuth 客户端 ID"。 |
||||
|
配置您的 OAuth 同意屏幕和应用程序类型，然后点击 "创建"。 |
||||
|
您的客户端 ID 和密钥将显示出来。 |
||||
|
有关更详细的说明，请访问 Google 的官方 [OAuth 2.0 设置指南](https://developers.google.com/identity/protocols/oauth2)。 |
||||
|
|
||||
|
</Tab> |
||||
|
|
||||
|
<Tab title="GitHub"> |
||||
|
|
||||
|
转到您的 GitHub 设置。 |
||||
|
点击 "开发人员设置"。 |
||||
|
点击 "OAuth 应用程序"，然后点击 "New OAuth App"。 |
||||
|
填写所需信息，然后点击 "注册应用程序"。 |
||||
|
客户端 ID 和密钥将显示在下一页上。 |
||||
|
您可以在 [GitHub OAuth 文档](https://docs.github.com/en/developers/apps/building-oauth-apps) 中找到更详细的说明。 |
||||
|
|
||||
|
</Tab> |
||||
|
|
||||
|
<Tab title="Discord"> |
||||
|
|
||||
|
转到 Discord 开发者门户。 |
||||
|
点击 "New Application"。 |
||||
|
给您的应用程序命名，然后点击 "创建"。 |
||||
|
转到您的应用程序设置中的 "OAuth2" 页面。 |
||||
|
在 "重定向" 下，添加您的重定向 URI。 |
||||
|
点击 "保存更改"。 |
||||
|
客户端 ID 可以在 "General Information" 页面找到，密钥可以在 "OAuth2" 页面找到。 |
||||
|
有关更详细的说明，请访问 [Discord OAuth2 文档](https://discord.com/developers/docs/topics/oauth2)。 |
||||
|
|
||||
|
</Tab> |
||||
|
</Tabs> |
||||
|
|
||||
|
## 启用非本地认证 |
||||
|
|
||||
|
`.env` 文件包含几个提供者客户端 ID 和密钥的占位符。请使用从各自提供者那里获取的密钥替换这些占位符： |
||||
|
|
||||
|
- 对于 Google，将 `GOOGLE_CLIENT_ID` 和 `GOOGLE_CLIENT_SECRET` 的 "\*\*\*" 占位符替换为从 Google 获取的客户端 ID 和密钥。 |
||||
|
- 对于 GitHub，将 `GITHUB_CLIENT_ID` 和 `GITHUB_CLIENT_SECRET` 的 "\*\*\*" 占位符替换为从 GitHub 获取的客户端 ID 和密钥。 |
||||
|
- 对于 Discord，将 `DISCORD_CLIENT_ID` 和 `DISCORD_CLIENT_SECRET` 的 "\*\*\*" 占位符替换为从 Discord 获取的客户端 ID 和密钥。 |
||||
|
|
||||
|
一旦进行了这些更改，您的应用程序将设置为使用这些提供者的 OAuth 认证。要从本地认证切换到 OAuth 认证，请将您的 `.env` 文件中的 `NEXTAUTH_URL` 变量更改为您的应用程序托管的 URL。这不能是 localhost。 |
||||
@ -0,0 +1,9 @@ |
|||||
|
--- |
||||
|
title: Embeddings |
||||
|
description: |
||||
|
icon: "page" |
||||
|
--- |
||||
|
|
||||
|
|
||||
|
|
||||
|
## 向量化 |
||||
@ -0,0 +1,57 @@ |
|||||
|
--- |
||||
|
title: 引擎 |
||||
|
description: |
||||
|
icon: "lightbulb" |
||||
|
--- |
||||
|
|
||||
|
|
||||
|
### 开源/闭源LLMs |
||||
|
|
||||
|
支持LLMs的有 openai 、 google （gemini）、 azureopenai 、 ollama 、 anthropic 、 mistral huggingface 和 groq 。 |
||||
|
|
||||
|
GPT-4 Turbo 模型（128K 上下文） |
||||
|
|
||||
|
|
||||
|
### LangGraph |
||||
|
|
||||
|
一个库，用于构建有LLMs状态的多参与者应用程序 |
||||
|
通过使用Langgraph，通过利用具有专业技能的多个代理，可以在深度和质量上显着提高研究过程。受最近的 STORM 论文的启发，这个例子展示了一个 AI 代理团队如何协同工作，对给定主题进行研究，从计划到发布 |
||||
|
|
||||
|
|
||||
|
|
||||
|
### 多代理团队 |
||||
|
|
||||
|
由 7 个 AI顾问组成一个Team |
||||
|
|
||||
|
- **Chief Editor(主编)** - 监督研究过程并管理团队。这是使用 Langgraph 协调其他代理的“主”代理 |
||||
|
- **Researcher(研究员)** - 对给定主题进行深入研究的专用自主代理 |
||||
|
- **Editor(编辑)** - 负责规划研究大纲和结构. |
||||
|
- **Reviewer(审稿人)** - 根据一组标准验证研究结果的正确性 |
||||
|
- **Revisor(修订者)** - 根据审稿人的反馈修改研究结果 |
||||
|
- **Writer(撰稿人)** - 负责编制和撰写最终报告 |
||||
|
- **Publisher(发布者)** - 负责以各种格式发布最终报告 |
||||
|
|
||||
|
|
||||
|
|
||||
|
### 运作方式 |
||||
|
|
||||
|
该过程基于以下阶段： |
||||
|
|
||||
|
1. 规划阶段 |
||||
|
2. 资料收集与分析 |
||||
|
3. 审查和修订 |
||||
|
4. 写作和投稿 |
||||
|
5. 出版发布 |
||||
|
|
||||
|
### 步骤 |
||||
|
|
||||
|
- Browser(浏览器) - 根据给定的研究任务浏览互联网进行初步研究 |
||||
|
- Editor(主编辑) - 根据初步研究计划报告大纲和结构。 |
||||
|
- 对于每个大纲主题（并行）: |
||||
|
- Researcher(研究员) - 对子主题进行深入研究并撰写草稿 |
||||
|
- Reviewer(审阅者) - 根据一组标准验证草稿的正确性并提供反馈 |
||||
|
- Revisor(修订者) - 根据审阅者的反馈修改草稿，直到满意为止 |
||||
|
- Writer(撰稿人) - 编译和撰写最终报告，包括给定研究结果的引言、结论和参考文献部分 |
||||
|
- Publisher(发布者) - 将最终报告发布为多种格式，例如 PDF、Docx、Markdown 等。 |
||||
|
|
||||
|
|
||||
@ -0,0 +1,29 @@ |
|||||
|
--- |
||||
|
title: Function Calling |
||||
|
description: |
||||
|
icon: "page" |
||||
|
--- |
||||
|
|
||||
|
## 什么是`Function Calling` |
||||
|
|
||||
|
## 大模型连接外部世界三种方式之一`GPTS` |
||||
|
|
||||
|
#### 用`Actions`连接外部世界 |
||||
|
通过GPTS等产品 大模型连接外部世界 |
||||
|
|
||||
|
## 大模型连接外部世界三种方式之一`Assistant API` |
||||
|
|
||||
|
|
||||
|
## 大模型连接外部世界三种方式之一`Function Calling` |
||||
|
|
||||
|
|
||||
|
## 交互接口的进化 |
||||
|
|
||||
|
什么是接口，接口如何进化；未来接口的方向是用自然语言与设备和系统交互 |
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
## `Function Calling`的机制 |
||||
|
|
||||
|
|
||||
@ -0,0 +1,35 @@ |
|||||
|
--- |
||||
|
title: 记忆 |
||||
|
description: 了解 WealthMentor 如何利用向量数据库管理记忆。 |
||||
|
icon: "brain" |
||||
|
--- |
||||
|
|
||||
|
# WealthMentor 中的记忆管理 |
||||
|
|
||||
|
在完成设定目标的探索过程中，AI 代理执行大量任务，考虑它们的执行历史。当代理运行时间较长时，记忆管理变得具有挑战性，因为它们的记忆通常与它们的上下文长度一样大。对于 GPT-3.5 和 GPT-4 来说，这大约是 8k - 128k 个标记。 |
||||
|
|
||||
|
## WealthMentor 的记忆困境 |
||||
|
|
||||
|
一旦您的代理运行了几次循环，它们就会忘记之前的行动。我们的解决方案？向量数据库。在这里，我们将代理记忆保存在外部，使其在需要时可以访问。 |
||||
|
|
||||
|
## 什么是向量数据库？ |
||||
|
|
||||
|
这个外部文档 - [Weaviate 文档](https://weaviate.io/developers/weaviate)，提供了详细的解释。简而言之，向量数据库使我们能够在外部存储任务执行历史。这样，代理可以通过文本相似性搜索从许多循环之前访问记忆。从本质上讲，人类检索记忆的方式与向量数据库的操作相似。 |
||||
|
|
||||
|
## 为什么选择 Weaviate？ |
||||
|
|
||||
|
Weaviate 是我们的首选向量数据库，原因如下： |
||||
|
|
||||
|
1. Weaviate 是开源的，并且可以通过 docker-compose 方便地访问，无需在本地 WealthMentor 运行时使用 API 密钥。 |
||||
|
2. 它的云服务可以根据我们的工作负载进行扩展，省去了管理额外基础设施的麻烦。 |
||||
|
3. Weaviate 与 LangChain 等工具无缝集成。 |
||||
|
|
||||
|
然而，如果您对其他数据库有建议，我们鼓励您创建一个工单或拉取请求。 |
||||
|
|
||||
|
## WealthMentor 中的记忆 |
||||
|
|
||||
|
长期记忆的使用仍然在不断发展中。到目前为止，以下是一些应用程序： |
||||
|
|
||||
|
- 在给定运行中使用的相似任务进行过滤。 |
||||
|
|
||||
|
我们正在积极开发更多应用程序。如果您对记忆管理有有趣的想法，或者希望为其发展做出贡献，请随时联系我们。 |
||||
@ -0,0 +1,100 @@ |
|||||
|
--- |
||||
|
title: 数据库prisma |
||||
|
description: |
||||
|
icon: "road" |
||||
|
--- |
||||
|
|
||||
|
Prisma 是一个开源的数据库工具链项目，不仅仅是一个简单的 ORM 工具。 |
||||
|
它支持的数据库有 PostgreSQL、MySQL、MongoDB、SQL Server和SQLite |
||||
|
|
||||
|
|
||||
|
https://juejin.cn/post/7231152303583100988 |
||||
|
|
||||
|
```bash |
||||
|
npx prisma --help |
||||
|
|
||||
|
# 生成了一个 schema 模板 prisma/schema.prisma |
||||
|
npx prisma init |
||||
|
|
||||
|
npx prisma migrate dev --name init |
||||
|
|
||||
|
npx prisma migrate dev --name add_foo_column |
||||
|
|
||||
|
``` |
||||
|
|
||||
|
# Prisma 提供的 7 个命令 |
||||
|
|
||||
|
1. **init** |
||||
|
- 在应用中初始化 Prisma |
||||
|
|
||||
|
2. **generate** |
||||
|
- 主要用来生成 Prisma Client |
||||
|
|
||||
|
3. **db** |
||||
|
- 管理数据库的模式和生命周期 |
||||
|
|
||||
|
4. **migrate** |
||||
|
- 迁移数据库 |
||||
|
|
||||
|
5. **studio** |
||||
|
- 启动一个 Web 端的工作台来管理数据 |
||||
|
|
||||
|
6. **validate** |
||||
|
- 检查 Prisma 的模式文件的语法是否正确 |
||||
|
|
||||
|
7. **format** |
||||
|
- 格式化 Prisma 的模式文件，默认是 `prisma/schema.prisma` |
||||
|
|
||||
|
|
||||
|
|
||||
|
以下是关于 Prisma 中定义 User 模型及其相关信息的 Markdown 说明： |
||||
|
|
||||
|
```markdown |
||||
|
# 定义 User 模型 |
||||
|
|
||||
|
作为 ORM 工具，Prisma 的模型主要有以下作用： |
||||
|
|
||||
|
- 构成了应用领域的 **实体** |
||||
|
- 映射到数据库的 **表**（关系型数据库，例如 PostgreSQL）或 **集合**（MongoDB） |
||||
|
- 构成 Prisma Client API 中 **查询** 的基础 |
||||
|
- 在使用 TypeScript 时，Prisma Client 为模型及其 **变体** 提供 **类型定义**，保证数据库访问的类型安全 |
||||
|
|
||||
|
定义模型时会用到形如 `@id()` 、`@default()` 这些 Prisma 内置的工具函数。比如 `@id()` 用来声明主键，`@default()` 用来设置默认值，命名都非常语义化，基本就是 SQL 中的一些关键字，非常容易理解。 |
||||
|
|
||||
|
下面是一个 User 模型的定义： |
||||
|
|
||||
|
```prisma |
||||
|
model User { |
||||
|
id Int @id @default(autoincrement()) |
||||
|
name String |
||||
|
email String @unique |
||||
|
password String |
||||
|
createdTime DateTime @default(now()) @map("created_time") |
||||
|
updatedTime DateTime @updatedAt @map("updated_time") |
||||
|
|
||||
|
@@map("user") |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
## 需要说明的几点信息： |
||||
|
|
||||
|
1. **模型的名字**默认就是创建的数据表的名字，这里是大写的 `User`，那么数据表名也就是大写的 `User`，可以使用 `@@map()` 来设置映射的表名，改为小写的 `user`。 |
||||
|
2. **主键**：每个模型的记录都是唯一可识别的，也就是要有主键，可以使用 `@id` 去声明。 |
||||
|
3. **字段的类型**：比如 `Int`，`String`，会经过 Prisma 转为数据库对应的类型，也就是 `int` 和 `varchar`。 |
||||
|
4. **唯一值约束**：`@unique` 是唯一值约束，所以生成的 `user` 表的 `email` 字段的值不能重复。 |
||||
|
5. **创建时间和更新时间**：为了符合 JS、TS 中的命名规范，使用了小驼峰命名，为了符合数据库命名规范，在后面使用 `@map()` 重新映射为了下划线命名。 |
||||
|
|
||||
|
## 同步数据库 |
||||
|
|
||||
|
将 Prisma 模型同步到数据库，对于我们这样一个新项目，可以使用下面的命令： |
||||
|
|
||||
|
```sh |
||||
|
$ npx prisma db push |
||||
|
``` |
||||
|
|
||||
|
如果是一个已经有数据的项目，就不能使用这个命令了，转而使用 `prisma migrate` 迁移。本文先不涉及。 |
||||
|
|
||||
|
它会创建数据库的 schema，并且使用 Prisma schema 同步数据库，还会“偷偷”执行 `prisma generate` 命令来生成 Prisma Client。 |
||||
|
``` |
||||
|
|
||||
|
这段 Markdown 文档包含了定义 Prisma User 模型的详细步骤和说明，格式清晰易读。 |
||||
@ -0,0 +1,77 @@ |
|||||
|
--- |
||||
|
title: 提示词 |
||||
|
description: 了解我们如何使用提示词来引导我们的人工智能代理的行为。 |
||||
|
icon: "page" |
||||
|
--- |
||||
|
|
||||
|
## 什么是提示词`Prompt` |
||||
|
|
||||
|
提示词在塑造我们的人工智能代理的行为方面发挥着关键作用，它们引导语言模型朝着实现特定任务或目标的方向发展。我们主要使用两个模型 `gpt-3.5-turbo` 和 `gpt-4`。所有这些模型都对提示中的最微小的细节非常敏感，这使得提示设计成为我们系统中至关重要的一个方面。 |
||||
|
|
||||
|
## 提示模板 |
||||
|
|
||||
|
除了这些强大的模型之外，我们还提供了各种预制的提示模板。这些模板在刚开始时可以作为宝贵的资源，提供了良好结构提示的优秀示例。然而，这些模板并不总是完美的，应该根据您特定的用例进行微调以最好地满足您的需求。每种情况都是独特的，最好的结果通常来自基于您独特的需求和目标进行的提示的迭代测试和细化。 |
||||
|
|
||||
|
## 开始使用提示 |
||||
|
|
||||
|
如果您对学习提示的艺术感兴趣，我们建议参考以下资源： |
||||
|
|
||||
|
1. [学习提示文档](https://learnprompting.org/) |
||||
|
2. [提示工程指南](https://www.promptingguide.ai/techniques/consistency) |
||||
|
3. [开发者的提示工程](https://www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers/) |
||||
|
|
||||
|
## 关键术语 |
||||
|
|
||||
|
1. **一次性 / 两次性 / N 次性**: 您提供 1、2 或 N 个示例与您的提示一起以提高模型准确性。 |
||||
|
2. **零次性**: 您直接向模型提供一个提示，而不提供任何示例。 |
||||
|
|
||||
|
## 在WealthMentor中的提示技术 |
||||
|
|
||||
|
### 计划与解决 |
||||
|
|
||||
|
计划与解决（PS）是一种增强思维链提示方法的技术。在PS中，模型被要求理解问题，提取相关变量和值，并制定逐步计划。我们主要使用这种零次方法来增加关于抽象目标的推理准确性。通过其 [GitHub 仓库](https://github.com/AGI-Edgerunners/Plan-and-Solve-Prompting) 了解更多关于计划与解决的信息。 |
||||
|
|
||||
|
### ReAct |
||||
|
|
||||
|
Reasoning + Action，简称为 ReAct，是一种将推理和行动生成结合到一个输出中的提示技术。这使得模型能够更好地将思想与行动同步。 |
||||
|
|
||||
|
|
||||
|
以下内容，其中 🔵 是指适合初学者的提示工程技术，而 🔴 是指进阶技术。 |
||||
|
|
||||
|
1. [🔵] 使用 CO-STAR 框架来搭建 prompt 的结构 |
||||
|
2. [🔵] 使用分隔符为 prompt 设置分节 |
||||
|
3. [🔴] 使用 LLM 防护围栏创建系统 prompt |
||||
|
4. [🔴] 仅使用 LLM 分析数据集，不使用插件或代码 —— 附带一个实操示例：使用 GPT-4 分析一个真实的 Kaggle 数据集。 |
||||
|
|
||||
|
其工作方式为： |
||||
|
|
||||
|
(C) 上下文（Context）：提供与任务有关的背景信息。这有助于 LLM 理解正在讨论的具体场景，从而确保其响应是相关的。 |
||||
|
(O) 目标（Objective）：定义你希望 LLM 执行的任务。明晰目标有助于 LLM 将自己响应重点放在完成具体任务上。 |
||||
|
(S) 风格（Style）：指定你希望 LLM 使用的写作风格。这可能是一位具体名人的写作风格，也可以是某种职业专家（比如商业分析师或 CEO）的风格。这能引导 LLM 使用符合你需求的方式和词语给出响应。 |
||||
|
(T) 语气（Tone）：设定响应的态度。这能确保 LLM 的响应符合所需的情感或情绪上下文，比如正式、幽默、善解人意等。 |
||||
|
(A) 受众（Audience）：确定响应的目标受众。针对具体受众（比如领域专家、初学者、孩童）定制 LLM 的响应，确保其在你所需的上下文中是适当的和可被理解的。 |
||||
|
(R) 响应（Response）：提供响应的格式。这能确保 LLM 输出你的下游任务所需的格式，比如列表、JSON、专业报告等。对于大多数通过程序化方法将 LLM 响应用于下游任务的 LLM 应用而言，理想的输出格式是 JSON |
||||
|
|
||||
|
|
||||
|
### 进阶 |
||||
|
|
||||
|
#### Prompt调优 |
||||
|
|
||||
|
1. 零样本提示 |
||||
|
|
||||
|
2. 少样本提示 |
||||
|
|
||||
|
|
||||
|
#### 技巧 |
||||
|
|
||||
|
1. 思维链(Chain-of-thought) |
||||
|
|
||||
|
|
||||
|
2. 自洽性(Self-Consistency) |
||||
|
|
||||
|
|
||||
|
3. 思维树(Tree-of-thought) |
||||
|
|
||||
|
|
||||
|
衍生出 network search API 和 embedding search 向量数据 |
||||
|
|
||||
@ -0,0 +1,20 @@ |
|||||
|
--- |
||||
|
title: RAG |
||||
|
description: 检索增强生成 |
||||
|
icon: "lightbulb" |
||||
|
--- |
||||
|
|
||||
|
|
||||
|
"RAG" 可能指的是 "Retrieval-Augmented Generation"（检索增强生成）模型。这是一种结合了检索和生成的人工智能模型，旨在提高生成式模型的效果和表现。 |
||||
|
|
||||
|
在传统的生成式模型中，例如基于Transformer架构的语言模型（如GPT），生成的文本是完全由模型内部学到的知识和模式产生的。然而，这种模型有时可能会产生不准确或不合理的文本，尤其是在生成长文本或需要特定领域知识的情况下。 |
||||
|
|
||||
|
为了解决这个问题，RAG模型引入了检索的思想。它在生成文本之前，首先使用一个检索模块来检索相关的文本片段或知识，然后将这些文本片段与生成模型结合起来，以指导生成过程。这样一来，生成的文本可以基于更加丰富和准确的信息，从而提高了生成文本的质量和相关性。 |
||||
|
|
||||
|
RAG模型通常由两个部分组成： |
||||
|
|
||||
|
1. **检索模块（Retriever）**：负责从一个大型的文本数据库或知识库中检索相关的文本片段或知识。检索模块可以使用传统的信息检索技术，也可以基于深度学习模型（如BERT）来实现。 |
||||
|
|
||||
|
2. **生成模块（Generator）**：负责根据检索到的文本片段生成最终的文本结果。生成模块通常是一个生成式的语言模型，如GPT。 |
||||
|
|
||||
|
通过将检索和生成相结合，RAG模型在生成文本时能够更加准确和可控，适用于许多需要高质量生成文本的任务，如问答系统、文档摘要、自动文本生成等。 |
||||
@ -0,0 +1,12 @@ |
|||||
|
--- |
||||
|
title: 报告 |
||||
|
description: |
||||
|
icon: "lightbulb" |
||||
|
--- |
||||
|
|
||||
|
### 类型 |
||||
|
|
||||
|
1. 研究报告 |
||||
|
2. 资源报表 |
||||
|
3. 大纲报告 |
||||
|
4. 量身定制的报告 |
||||
@ -0,0 +1,9 @@ |
|||||
|
--- |
||||
|
title: 爬虫 |
||||
|
description: |
||||
|
icon: "lightbulb" |
||||
|
--- |
||||
|
|
||||
|
对于搜索引擎，我们推荐 Tavily Search API |
||||
|
|
||||
|
收集有关代码文档、业务分析、财务信息等的信息 |
||||
@ -0,0 +1,71 @@ |
|||||
|
--- |
||||
|
title: API 接口 |
||||
|
description: 用于设置 WealthMentor 本地安装的指南。 |
||||
|
icon: "gear" |
||||
|
--- |
||||
|
|
||||
|
本文旨在指导您完成在本地安装 WealthMentor 的过程。重要的是要注意，我们建议使用 Docker 进行此安装。Docker 简化了该过程，并确保所有依赖项都得到正确处理，使安装过程更加简单和不易出错。 |
||||
|
|
||||
|
## 先决条件 |
||||
|
|
||||
|
在开始之前，请确保您已安装以下内容： |
||||
|
|
||||
|
1. [Git](https://git-scm.com/downloads) |
||||
|
2. [Node.js](https://nodejs.org/en/download) |
||||
|
3. [OpenAI API 密钥](https://beta.openai.com/signup/) |
||||
|
4. 任意您选择的代码编辑器，如 [Visual Studio Code (VS Code)](https://code.visualstudio.com/download) |
||||
|
|
||||
|
### Docker 安装（推荐） |
||||
|
|
||||
|
除了上述先决条件外，还需要 Docker 进行此设置。按照以下步骤进行 Docker 安装： |
||||
|
|
||||
|
1. 下载并安装 [Docker](https://www.docker.com/products/docker-desktop) |
||||
|
2. 安装完成后，如果尚未拥有 Docker 帐户，则创建一个 |
||||
|
3. 打开 Docker Desktop 应用并登录 |
||||
|
|
||||
|
## 使用 Docker 安装 |
||||
|
|
||||
|
1. **打开您的编辑器** |
||||
|
|
||||
|
2. **打开终端** - 通常可以在“终端”选项卡中执行此操作，也可以使用快捷键 |
||||
|
（例如，在 VS Code 中，Windows 为 `Ctrl + ~`，Mac 为 `Control + ~`）。 |
||||
|
|
||||
|
3. **克隆存储库并进入目录** - 终端打开后，可以运行以下命令来克隆存储库并进入目录。 |
||||
|
|
||||
|
|
||||
|
|
||||
|
4. **按照脚本的设置说明操作** - 添加适当的 API 密钥，一旦所有服务都运行起来，就打开您的 Web 浏览器前往 [http://localhost:3000](http://localhost:3000)。 |
||||
|
|
||||
|
## 不使用 Docker 安装 |
||||
|
|
||||
|
在 Docker 外部，您只需配置您的环境。此外，您可以使用 `setup.sh` 配置您的环境并更新 Prisma 配置以指向本地 SQLite 实例。 |
||||
|
|
||||
|
完成此操作后，您可以运行以下命令来设置 Next.js 项目。 |
||||
|
|
||||
|
```bash |
||||
|
// 前端 |
||||
|
cd ./next |
||||
|
npm install |
||||
|
npm run dev |
||||
|
``` |
||||
|
|
||||
|
在另一个窗口中，您可以运行以下命令来启动后端： |
||||
|
|
||||
|
```bash |
||||
|
// 后端。确保您位于项目的根目录 |
||||
|
cd ./platform |
||||
|
poetry install |
||||
|
poetry run python -m reworkd_platform |
||||
|
``` |
||||
|
|
||||
|
## 运行站点 |
||||
|
|
||||
|
恭喜您成功在本地计算机上设置了 WealthMentor！要查看您的工作成果，请打开您首选的 Web 浏览器，并访问 [http://localhost:3000/](http://localhost:3000/)。在那里，您会发现 WealthMentor 用户界面已准备好供您探索和交互。 |
||||
|
|
||||
|
## 问题 / 额外帮助 |
||||
|
|
||||
|
尽管有详细的说明，但您可能仍然会遇到一些问题。如果发生这种情况，不用担心！我们会帮助您。考虑参考此详细的旧版指南，它会为您提供详细的步骤：[如何在本地安装 WealthMentor](https://snapdragon-writer-867.notion.site/How-to-Install-WealthMentor-Locally-9b96b2314c9b491397976249fd121023)。 |
||||
|
|
||||
|
如果问题仍然存在，我们邀请您在 GitHub 上提交一个 [问题](https://github.com/reworkd/WealthMentor/issues)。通过这样做，您不仅会得到帮助，还会帮助我们识别任何可能存在问题的地方以加以改进。或者，您可以在 [Discord](https://discord.gg/jdSBAnmdnY) 上联系我们专注的团队。我们是一个学习者和爱好者的社区，随时准备伸出援手。 |
||||
|
|
||||
|
祝您愉快地编程，并享受与 WealthMentor 的旅程！ |
||||
@ -0,0 +1,90 @@ |
|||||
|
--- |
||||
|
title: "Translations" |
||||
|
description: Guide to translaitng the language. |
||||
|
icon: "globe" |
||||
|
--- |
||||
|
|
||||
|
WealthMentor has translations across a variety of languages thanks to the help of many contributors such as @Cs4K1Sr4C. |
||||
|
languages. We're always looking to improve our translations however, if you notice something is off or missing, please |
||||
|
feel free to make the necessary updates or submit a ticket on GitHub! |
||||
|
|
||||
|
## Translating the Frontend |
||||
|
|
||||
|
We use i18next to handle our frontend translations. How it works is we have a folder for each language |
||||
|
in [next/public/locales](https://github.com/reworkd/WealthMentor/tree/main/next/public/locales). |
||||
|
|
||||
|
```bash title="next/public/locales" |
||||
|
> en |
||||
|
> fr |
||||
|
> hu |
||||
|
... |
||||
|
> zh |
||||
|
``` |
||||
|
|
||||
|
For each component within the app, we namespace their translations. For example, our ChatWindow uses the `chat` name |
||||
|
space and its translations will be found in the `chat.json` under each folder. Translations are key value pairs where |
||||
|
the key represents the |
||||
|
desired text and the value represents the translation for a given langauge. |
||||
|
|
||||
|
An example from the `chat` namespace: |
||||
|
|
||||
|
- English: `"EMBARKING_ON_NEW_GOAL": "Embarking on a new goal:"` |
||||
|
- Spanish:`"EMBARKING_ON_NEW_GOAL": "Embarcándose en un nuevo objetivo:"` |
||||
|
|
||||
|
#### Adding a new langauge |
||||
|
|
||||
|
To add a new language, go into our i18 config and add a new locale |
||||
|
|
||||
|
```bash title="next/next-i18next.config.js" |
||||
|
i18n: { |
||||
|
defaultLocale: "en", |
||||
|
locales: |
||||
|
[ |
||||
|
"en", |
||||
|
"hu", |
||||
|
..., |
||||
|
"sk", |
||||
|
"hr", |
||||
|
"tr", |
||||
|
// Insert new language code here |
||||
|
], |
||||
|
... |
||||
|
``` |
||||
|
|
||||
|
Then head over to our languages definition and add a section to the available languages list |
||||
|
|
||||
|
```tsx title="next/src/utils/languages.ts" |
||||
|
export const availableLanguages: Language[] = [ |
||||
|
ENGLISH, |
||||
|
{ code: "fr", name: "Français", flag: "🇫🇷" }, |
||||
|
// ... |
||||
|
{ code: "tr", name: "Türkçe", flag: "🇹🇷" }, |
||||
|
// Insert new language here |
||||
|
]; |
||||
|
``` |
||||
|
|
||||
|
After this, you must create a new folder with your langauge code |
||||
|
in [next/public/locales](https://github.com/reworkd/WealthMentor/tree/main/next/public/locales) and add translations for all |
||||
|
namespaces of our app. Note these values may not hot reload, so you must manually restart your next server. |
||||
|
|
||||
|
## Translating the Backend |
||||
|
|
||||
|
The backend translations are handled via the model itself. |
||||
|
We simply prompt it to provide the answer in the user selected langauge. |
||||
|
This means that whenever a new frontend language is added, the language is immediately supported on the backend! |
||||
|
This does however mean that we don't currently have much room to actually edit the translations provided by the model. |
||||
|
|
||||
|
## Translating the Readme |
||||
|
|
||||
|
We have a few README translations that live in [main/docs](https://github.com/reworkd/WealthMentor/tree/main/docs) such |
||||
|
as `README.zh-HANS.md`. If you'd like to translate the README to your language, make a similar file. |
||||
|
|
||||
|
After doing this, add a link badge to our main english README alongside the other badges. Example: |
||||
|
|
||||
|
<a href="https://github.com/reworkd/WealthMentor/blob/master/README.md"> |
||||
|
<img src="https://img.shields.io/badge/lang-English-blue.svg" alt="English" /> |
||||
|
</a> |
||||
|
|
||||
|
## Translating our Documentation |
||||
|
|
||||
|
This documentation is very experimental. Because of this, we have no plans to support translation just yet. |
||||
@ -0,0 +1,28 @@ |
|||||
|
--- |
||||
|
title: "Input Templating" |
||||
|
description: The workflow automation system within WealthMentor. |
||||
|
icon: "wave-sine" |
||||
|
--- |
||||
|
|
||||
|
Any given workflow node will outfield a set of fields that can be used in the input of descendent nodes. |
||||
|
Because these outputs are only generated at runtime, we use a templating system to keep track of what values a node |
||||
|
will receive once these values are actually calculated. |
||||
|
This document goes over how this process works in both the frontend and backend. |
||||
|
|
||||
|
## Model |
||||
|
All `block` definitions will specify both the inputs it takes in and the output values it provides |
||||
|
|
||||
|
|
||||
|
## Frontend |
||||
|
The workflow hierarchy follows a graph-like structure. |
||||
|
For a given node, we calculate what output fields are available to it by doing a BFS on its ascendant nodes. |
||||
|
Once we have a list of all ascendant nodes, we can generate the available output field values along with its underlying key. |
||||
|
When placed inside the input of another node, it will take its template form which has the following shape: |
||||
|
|
||||
|
``` |
||||
|
{{node_id-value}} |
||||
|
``` |
||||
|
|
||||
|
## Backend |
||||
|
A workflow task in kafka will keep track of the mapping of template key to value pairs as they are generated. |
||||
|
When a new node is being executed, its input fields will first have actual values replace the string templates before type validation is run. |
||||
@ -0,0 +1,43 @@ |
|||||
|
--- |
||||
|
title: "工作流" |
||||
|
description: WealthMentor 内的工作流自动化系统。 |
||||
|
icon: "wave-sine" |
||||
|
--- |
||||
|
|
||||
|
Reworkd 的核心功能是由 AI 驱动的工作流自动化。本文档涵盖了我们工作流平台的关键概念。 |
||||
|
|
||||
|
## 前端模型 |
||||
|
工作流层次结构遵循类似图形的结构。前端模型只规定了工作流的前端视图。 |
||||
|
|
||||
|
- 工作流是图形本身。它代表了整个工作流 |
||||
|
- 节点是工作流中的单个元素。它具有位置 |
||||
|
- 边表示工作流中两个节点之间的连接 |
||||
|
|
||||
|
## 后端模型 |
||||
|
后端模型表示实际执行给定节点工作的机制。 |
||||
|
每个前端 `Node` 将具有关联的 `Block`。 |
||||
|
`Node` 表示前端视图 / 位置，而 `Block` 表示当该 `Node` 运行时将实际发生的情况。 |
||||
|
例如，"SlackMessageBlock" 是一个 `Block`，当执行时，它会在 "Slack" 上向用户发送消息。 |
||||
|
|
||||
|
## 添加新块 |
||||
|
要添加新块，请从更新前端开始： |
||||
|
- 打开 next/src/services/workflow/node-block-definitions.ts |
||||
|
- 搞定它 |
||||
|
- （很快前端的块定义将从后端设置，不需要在此处进行编辑） |
||||
|
|
||||
|
然后更新后端： |
||||
|
- 打开 platform/reworkd_platform/schemas/workflow/blocks |
||||
|
- 为您的块添加一个新文件 |
||||
|
- 将块的输入和输出类型定义为类 |
||||
|
- 为块添加一个类，其中包括 |
||||
|
- 属性：类型、描述、图像 URL 和输入 |
||||
|
- 异步方法：`run` |
||||
|
- 使用 `poetry add` 为您的块安装依赖项 |
||||
|
- 打开 platform/reworkd_platform/web/api/workflow/blocks/web/__init__.py |
||||
|
- 导入您的块 |
||||
|
- 添加一个 if 分支到 get_block_runner |
||||
|
- `docker compose down; docker compose up --build` |
||||
|
|
||||
|
## 节点类型 |
||||
|
- 触发器：指定工作流如何运行 |
||||
|
- 操作：执行一个具体的 "工作" pièce |
||||
@ -1,4 +1,127 @@ |
|||||
--- |
--- |
||||
title: 简介 |
|
||||
description: "本文档详细描述如何在 DApp 中与以太坊钱包（如 MetaMask）交互，包括连接钱包、获取账户及对数据进行签名的具体方法。" |
|
||||
|
title: 关于 BUZZUP 网络 |
||||
|
description: "一个运行以太坊虚拟机 （EVM） 的无需许可的通用区块链。新系统将变得可访问、透明、去中心化和免费" |
||||
--- |
--- |
||||
|
|
||||
|
|
||||
|
|
||||
|
### 区块链网络架构 |
||||
|
|
||||
|
 |
||||
|
|
||||
|
```plaintext |
||||
|
+-------------------+ +-------------------+ |
||||
|
| | | | |
||||
|
| L1节点 | | L2节点 | |
||||
|
| 守护节点 |<---------------->| 终端节点 | |
||||
|
| | | | |
||||
|
| - 监测Edge节点 | | - 资源奖励 | |
||||
|
| - 提供基础设施 | | - 带宽奖励 | |
||||
|
| - 在线率评估 | | - 在线奖励 | |
||||
|
| - 报告Validator | | - 服务质量监控 | |
||||
|
| - 接收资源请求 | | | |
||||
|
| - 发送指令 | | | |
||||
|
+-------------------+ +-------------------+ |
||||
|
| | |
||||
|
| | |
||||
|
v v |
||||
|
+-------------------+ +-------------------+ |
||||
|
| | | | |
||||
|
| Validator节点 |<------------------->| Edge节点 | |
||||
|
| | | | |
||||
|
| - 确认交易 | | - 传输数据 | |
||||
|
| - 管理节点 | | - 数据存储 | |
||||
|
| - 验证Guardian | | - 数据处理 | |
||||
|
| - 性能评估 | | - 提供接口 | |
||||
|
| - 进行惩罚与奖励| | | |
||||
|
| - 接收监测数据 | | | |
||||
|
+-------------------+ +-------------------+ |
||||
|
|
||||
|
``` |
||||
|
|
||||
|
#### 模块化架构 |
||||
|
|
||||
|
``` |
||||
|
|
||||
|
|
||||
|
+-----------------------------------------------------+ |
||||
|
| L1层 | |
||||
|
| (Guardian守护节点模块) | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | 监测Edge节点 | | 提供基础设施 | | |
||||
|
| | (监测与评估模块) | | (服务模块) | | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | | | |
||||
|
| | | | |
||||
|
| v v | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | 在线率评估 | | 报告Validator | | |
||||
|
| | (评估模块) | | (报告模块) | | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | | | |
||||
|
| +-----------------------+--------------+ |
||||
|
| | |
||||
|
| v |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | 接收资源请求 | | 发送指令给L2节点| | |
||||
|
| | (资源管理模块) | | (指令模块) | | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
+-----------------------------------------------------+ |
||||
|
| |
||||
|
| |
||||
|
v |
||||
|
+-----------------------------------------------------+ |
||||
|
| L2层 | |
||||
|
| (终端节点模块) | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | 接收指令 | | 执行服务请求 | | |
||||
|
| | (指令处理模块) | | (服务模块) | | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | | | |
||||
|
| | | | |
||||
|
| v v | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | 返回状态反馈 | | 计算资源奖励 | | |
||||
|
| | (反馈模块) | | (奖励模块) | | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | | | |
||||
|
| +-----------------------+--------------+ |
||||
|
| | |
||||
|
| v |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
| | 发送用户数据 | | | | |
||||
|
| | (数据传输模块) | | | | |
||||
|
| +-------------------------+ +------------------+ | |
||||
|
+-----------------------------------------------------+ |
||||
|
|
||||
|
``` |
||||
|
|
||||
|
### 详细说明 |
||||
|
|
||||
|
#### 1. **L1节点（Guardian守护节点）** |
||||
|
- **监测Edge节点**: 定期监测和评估Edge节点的性能指标（如延迟、可用性）。 |
||||
|
- **提供基础设施**: 保障网络的存储、带宽和计算能力。 |
||||
|
- **在线率评估**: 实时评估节点在线状态，调整资源分配。 |
||||
|
- **报告Validator**: 向Validator发送Edge节点的监测报告。 |
||||
|
- **接收资源请求**: 根据网络状态动态接收和处理资源请求。 |
||||
|
- **发送指令**: 将指令推送到L2节点，确保服务的顺利进行。 |
||||
|
|
||||
|
#### 2. **L2节点（终端节点）** |
||||
|
- **资源奖励**: 根据用户的活动和在线状态进行奖励。 |
||||
|
- **带宽奖励**: 监测带宽使用情况并发放相应的奖励。 |
||||
|
- **在线奖励**: 根据用户在线时间给予额外奖励。 |
||||
|
- **服务质量监控**: 收集用户反馈并上报给L1和Validator。 |
||||
|
|
||||
|
#### 3. **Validator验证节点** |
||||
|
- **确认交易**: 验证并确认所有交易，确保其合法性。 |
||||
|
- **管理节点**: 协调L1和L2节点的活动，优化整体性能。 |
||||
|
- **验证Guardian守护节点**: 定期评估Guardian节点的表现。 |
||||
|
- **性能评估**: 监控各节点的性能数据，进行分析和优化。 |
||||
|
- **进行惩罚与奖励**: 基于评估结果，实施惩罚或奖励措施。 |
||||
|
- **接收监测数据**: 收集L1节点反馈的监测数据，以调整策略。 |
||||
|
|
||||
|
#### 4. **Edge(网络边缘)节点** |
||||
|
- **传输数据**: 高效传输和存储用户数据，保障服务质量。 |
||||
|
- **数据存储**: 提供可靠的数据存储解决方案。 |
||||
|
- **数据处理**: 处理实时数据请求，支持用户操作。 |
||||
|
- **提供接口**: 为用户和其他Edge节点提供数据访问接口。 |
||||
@ -0,0 +1,67 @@ |
|||||
|
--- |
||||
|
sidebar_label: 候选人申请 |
||||
|
hide_title: true |
||||
|
title: 候选人申请 |
||||
|
--- |
||||
|
|
||||
|
## 1. 序言 |
||||
|
|
||||
|
## 2. 环境搭建 |
||||
|
本文以 `Ubuntu 20.04` 系统为例搭建开发环境，首先需要安装依赖项，依赖项没有安装好的话, |
||||
|
|
||||
|
```bash |
||||
|
sudo apt install libgmp-dev cmake net-tools aria2 zstd unzip make mesa-opencl-icd ocl-icd-opencl-dev gcc git bzr jq pkg-config curl clang build-essential vim hwloc libhwloc-dev htop iotop nvtop tree xfsprogs ntpdate fio ansible iperf3 iperf iftop nfs-common firewalld tmux sshpass expect numactl libssl-dev -y && sudo apt upgrade -y |
||||
|
|
||||
|
``` |
||||
|
|
||||
|
## |
||||
|
|
||||
|
|
||||
|
## docker |
||||
|
|
||||
|
## 源码编译 |
||||
|
|
||||
|
|
||||
|
|
||||
|
## 发起申请 |
||||
|
|
||||
|
|
||||
|
|
||||
|
- **验证节点要求** |
||||
|
|
||||
|
```text |
||||
|
* 4 个或更多物理CPU核心 |
||||
|
* 至少 2T NVME SSD磁盘存储 |
||||
|
* 至少 32GB RAM |
||||
|
* 至少 100mbps 网络带宽 |
||||
|
``` |
||||
|
|
||||
|
|
||||
|
|
||||
|
- **通过官网写申请表单** |
||||
|
|
||||
|
|
||||
|
- 填写申请表单 |
||||
|
|
||||
|
|
||||
|
|
||||
|
- 提交申请单并等待审核结果 |
||||
|
|
||||
|
默认审核直接通过 |
||||
|
|
||||
|
|
||||
|
## 质押token |
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
- **发送质押消息** |
||||
|
|
||||
|
申请通过后，在节点主机上进行如下操作并成为候选节点，质押金额--amount要求跟申请单中金额保持一致 |
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
@ -0,0 +1,7 @@ |
|||||
|
--- |
||||
|
title: "区块链浏览器" |
||||
|
description: 这是专为网络设计的强大工具，旨在为用户提供便捷的区块链数据查询和分析服务 |
||||
|
--- |
||||
|
|
||||
|
|
||||
|
[BUZZUP chain explorer](http://193.200.130.186:8488/) |
||||
@ -0,0 +1,4 @@ |
|||||
|
--- |
||||
|
title: 关于 Layer 1 Chain |
||||
|
description: "本文档详细描述如何在 DApp 中与以太坊钱包（如 MetaMask）交互，包括连接钱包、获取账户及对数据进行签名的具体方法。" |
||||
|
--- |
||||
@ -0,0 +1,20 @@ |
|||||
|
--- |
||||
|
title: "质押" |
||||
|
description: 这是专为网络设计的强大工具，旨在为用户提供便捷的区块链数据查询和分析服务 |
||||
|
--- |
||||
|
|
||||
|
连接您的钱包 进行操作 |
||||
|
|
||||
|
### 如何质押 |
||||
|
|
||||
|
通过验证者 委托 进行质押 |
||||
|
|
||||
|
|
||||
|
### 领取奖励 |
||||
|
|
||||
|
必须为您委托的每个验证者单独领取奖励 |
||||
|
|
||||
|
|
||||
|
|
||||
|
### 取消质押 |
||||
|
|
||||
@ -0,0 +1,91 @@ |
|||||
|
--- |
||||
|
title: "验证者" |
||||
|
description: 作为保护网络的交换，验证者可以对分配给委托人的质押奖励 |
||||
|
--- |
||||
|
|
||||
|
#### 3. **Validator验证节点** |
||||
|
- **确认交易**: 验证并确认所有交易，确保其合法性。 |
||||
|
- **管理节点**: 协调L1和L2节点的活动，优化整体性能。 |
||||
|
- **验证Guardian守护节点**: 定期评估Guardian节点的表现。 |
||||
|
- **性能评估**: 监控各节点的性能数据，进行分析和优化。 |
||||
|
- **进行惩罚与奖励**: 基于评估结果，实施惩罚或奖励措施。 |
||||
|
- **接收监测数据**: 收集L1节点反馈的监测数据，以调整策略。 |
||||
|
|
||||
|
|
||||
|
|
||||
|
#### L1节点(暂定平台担当) |
||||
|
|
||||
|
**L1 - Guardian守护节点** |
||||
|
|
||||
|
**职责和重要性：** |
||||
|
- 主要面向IDC和稳定的基础设施提供商。 |
||||
|
- 作为基础设施提供商，与Validator和Edge节点协作，提供高质量的存储、带宽和计算服务。 |
||||
|
- 监测和评估Edge节点的服务质量，向Validator报告结果。 |
||||
|
|
||||
|
**在线时长：** |
||||
|
- 必须全天在线。 |
||||
|
|
||||
|
**质押：** |
||||
|
- 需要质押（测试网期间内无需质押），但没有固定的服务时间限制，可以随时加入和退出。 |
||||
|
|
||||
|
**配置要求：** |
||||
|
- **暂定配置：** |
||||
|
- CPU: 16核+ |
||||
|
- 内存: 16G+ |
||||
|
- 存储: 10T+ |
||||
|
- 带宽: 上下行200 Mbps |
||||
|
- 固定公网IP（IDC） |
||||
|
|
||||
|
**考察期：** |
||||
|
- 新加入的Guardian守护节点需经过考察评估，时长为网络的86400个区块（每个区块5秒）。 |
||||
|
- 考察期内节点不获得奖励，Validator将对新节点进行检查，确保其稳定性和安全性。 |
||||
|
|
||||
|
**冷静期：** |
||||
|
- 退出Network的Guardian节点需经历259200个区块的冷静期（每个区块5秒）。 |
||||
|
- 期间必须保持在线并继续贡献资源，冷静期结束后可取回质押币和奖励。 |
||||
|
|
||||
|
|
||||
|
### L1 节点奖励规则 |
||||
|
|
||||
|
#### 奖励制度调整 |
||||
|
- **调整方式**: 奖励从“任务分配”改为“租用制”。 |
||||
|
- **新增惩罚机制**: 对节点的不稳定性和作弊行为进行惩罚。 |
||||
|
|
||||
|
当然可以！以下是关于奖励计算的详细说明，采用了更为简洁的文本方式。 |
||||
|
|
||||
|
### 奖励计算概述 |
||||
|
|
||||
|
1. **每日总奖励**：系统每天会发放 **200,000 TNT3** 的总奖励。 |
||||
|
|
||||
|
2. **每日发放次数**：奖励将以 **288 次** 的频率发放，意味着每5分钟发放一次。 |
||||
|
|
||||
|
3. **在线率**：在线率是指用户过去7天的在线参与情况，表示为百分比。例如，95%的在线率可以表示为0.95。 |
||||
|
|
||||
|
### 基础奖励计算 |
||||
|
|
||||
|
- 每5分钟的基础奖励可以通过将每日总奖励（200,000 TNT3）除以每日发放次数（288次）来计算。结果大约为 **694.44 TNT3**。 |
||||
|
|
||||
|
### 在线率计算 |
||||
|
|
||||
|
- 在线率的计算公式是： |
||||
|
- 在线率 = （过去7天参与的心跳次数 / 过去7天需参与的总心跳次数）× 100% |
||||
|
- 如果用户在线的时间不足7天，则按照实际在线的天数进行计算，第一天和最新一天不算在内。 |
||||
|
|
||||
|
### 奖励标准 |
||||
|
|
||||
|
根据不同的在线率，奖励发放标准如下： |
||||
|
|
||||
|
- **98% - 100% 的在线率**：奖励为基础奖励的 **110%**。 |
||||
|
- 每5分钟奖励 = 694.44 × 在线率 × 1.10 |
||||
|
|
||||
|
- **95% - 98% 的在线率**：奖励为基础奖励的 **100%**。 |
||||
|
- 每5分钟奖励 = 694.44 × 在线率 |
||||
|
|
||||
|
- **85% - 95% 的在线率**：奖励为基础奖励的 **80%**。 |
||||
|
- 每5分钟奖励 = 694.44 × 在线率 × 0.80 |
||||
|
|
||||
|
- **30% - 85% 的在线率**：奖励为基础奖励的 **50%**。 |
||||
|
- 每5分钟奖励 = 694.44 × 在线率 × 0.50 |
||||
|
|
||||
|
- **低于30% 的在线率**：没有奖励。 |
||||
|
- 每5分钟奖励 = 0 |
||||
@ -0,0 +1,26 @@ |
|||||
|
--- |
||||
|
title: "Buzzup 钱包" |
||||
|
description: 这是专为网络设计的强大工具，旨在为用户提供便捷的区块链数据查询和分析服务 |
||||
|
--- |
||||
|
|
||||
|
### APP下载 |
||||
|
|
||||
|
|
||||
|
### 使用 MetaMask |
||||
|
|
||||
|
假设您已经在所选浏览器中安装并配置了 MetaMask，请按照以下步骤添加 Buzzup 网络： |
||||
|
|
||||
|
1. 打开 MetaMask 扩展 |
||||
|
1. 在界面顶部，单击您连接的网络，例如“以太坊主网”。 |
||||
|
1. 点击“添加网络”： |
||||
|
1. 输入以下 RPC 设置： |
||||
|
|
||||
|
```bash |
||||
|
|
||||
|
Network Name: Buzzup chain TestNet |
||||
|
New RPC URL: http://193.200.130.186:8545 |
||||
|
Chain ID: 1264 |
||||
|
Currency Symbol: BUZZ |
||||
|
Block Explorer URL: http://193.200.130.186:8488/ |
||||
|
|
||||
|
``` |
||||
@ -0,0 +1,127 @@ |
|||||
|
--- |
||||
|
title: 边缘设备(Edge) |
||||
|
description: "" |
||||
|
--- |
||||
|
|
||||
|
|
||||
|
#### 4. **Edge(网络边缘)节点** |
||||
|
- **传输数据**: 高效传输和存储用户数据，保障服务质量。 |
||||
|
- **数据存储**: 提供可靠的数据存储解决方案。 |
||||
|
- **数据处理**: 处理实时数据请求，支持用户操作。 |
||||
|
- **提供接口**: 为用户和其他Edge节点提供数据访问接口。 |
||||
|
|
||||
|
|
||||
|
### L2 - 终端节点 |
||||
|
|
||||
|
#### 参与奖励方式 |
||||
|
|
||||
|
1. **基础在线奖励** |
||||
|
- **说明**：通过成功运行 L2节点获得的奖励，每5秒增加一次。 |
||||
|
- **奖励基数**：不同设备端的奖励基数不同： |
||||
|
- **移动端设备**：手机 |
||||
|
- **PC桌面端**：Windows和macOS |
||||
|
- **其他设备**：VPS、边缘IoT设备等 |
||||
|
|
||||
|
2. **资源奖励（Proof of Availability, POA）** |
||||
|
- **说明**：用于验证资源有效性及提供服务的机制。 |
||||
|
- **包含内容**： |
||||
|
- 上行带宽奖励 |
||||
|
- NAT评分奖励 |
||||
|
- 已使用存储空间奖励 |
||||
|
|
||||
|
--- |
||||
|
|
||||
|
#### POA资源奖励机制 |
||||
|
|
||||
|
- **资源验证频率**：每天48个检查时间窗口（每30分钟一次）。 |
||||
|
- **验证方式**： |
||||
|
- **随机验证**：12次随机验证，基于实际测量结果计算奖励。 |
||||
|
- **历史表现**：剩余36次根据最近10次历史表现的平均值计算。 |
||||
|
|
||||
|
--- |
||||
|
|
||||
|
#### 奖励与惩罚 |
||||
|
|
||||
|
- **奖励**：验证一致的节点将获得POA奖励，以鼓励维护数据完整性。 |
||||
|
- **惩罚**：验证不一致的节点将不获得该轮POA的奖励，并受到适当惩罚。 |
||||
|
|
||||
|
--- |
||||
|
|
||||
|
#### 带宽奖励 |
||||
|
|
||||
|
- **说明**：L2节点支持运行WASM/JS容器，通过节点部署项目获得直接的带宽收益。 |
||||
|
|
||||
|
--- |
||||
|
|
||||
|
### NAT评分 |
||||
|
|
||||
|
|
||||
|
NAT（网络地址转换，Network Address Translation）是一种将私有IP地址转换为公网IP地址的技术。它允许多个设备共享同一个公网IP地址，通过修改数据包的源或目标IP地址，使得内部网络中的设备能够与外部网络（如互联网）进行通信。 |
||||
|
|
||||
|
#### NAT类型与评分 |
||||
|
|
||||
|
不同类型的NAT会影响网络的连接性和性能，因此在评分系统中赋予了不同的权重。以下是各NAT类型及其对应评分的详细信息： |
||||
|
|
||||
|
| **NAT类型** | **评分** | |
||||
|
|---------------------|-------| |
||||
|
| **公网IP** | 1.5 | |
||||
|
| **NAT 1 (Full Cone)** | 1.4 | |
||||
|
| **NAT 2** | 1.3 | |
||||
|
| **NAT 3** | 1.1 | |
||||
|
| **NAT 4 (Symmetric)** | 1.0 | |
||||
|
|
||||
|
#### 评分说明 |
||||
|
|
||||
|
- **公网IP（1.5分）**：用户直接连接到公网IP，提供最佳的连接性能和最低的延迟，评分最高。 |
||||
|
|
||||
|
- **NAT 1 (Full Cone, 1.4分)**：可以从任何外部主机接收流量，适合点对点连接，评分次高。 |
||||
|
|
||||
|
- **NAT 2（1.3分）**：允许内部设备接收来自已知外部设备的流量，评分中等。 |
||||
|
|
||||
|
- **NAT 3（1.1分）**：只能接收来自已知外部主机的流量，连接性较差，评分偏低。 |
||||
|
|
||||
|
- **NAT 4 (Symmetric, 1.0分)**：最严格的NAT类型，连接性最差，评分最低，可能会导致更高的延迟和不稳定性。 |
||||
|
|
||||
|
|
||||
|
--- |
||||
|
|
||||
|
### 存储奖励说明 |
||||
|
|
||||
|
存储奖励是根据验证节点测量的可用存储空间容量来评估和奖励的。具体的计算方式如下： |
||||
|
|
||||
|
#### 计算公式 |
||||
|
|
||||
|
我们使用以下公式来计算存储奖励： |
||||
|
|
||||
|
- **\( M_S \)**：存储奖励 |
||||
|
- **计算公式**： |
||||
|
|
||||
|
M_S = M_X × M_O × min(S × 12.5, 2000) × (1/10 + 1/max(min(S × 12.5, 2000), 10)) |
||||
|
|
||||
|
#### 公式中各符号的含义 |
||||
|
|
||||
|
1. **存储容量 \( S \)**： |
||||
|
- 表示存储设备的可用空间，以GB为单位。 |
||||
|
- 在计算中，存储容量会乘以12.5，以调整其对奖励的影响，并且通过 `min` 函数确保结果不超过2000。 |
||||
|
|
||||
|
2. **网络稳定性 \( M_X \)**： |
||||
|
- 这是一个系数，表示网络的稳定性。网络越稳定，\( M_X \) 值越高，意味着奖励也会随之增加。 |
||||
|
|
||||
|
3. **在线状态 \( M_O \)**： |
||||
|
- 此系数反映了用户的在线状态。用户在线时间越长，\( M_O \) 的值越高，这也将提高最终的奖励。 |
||||
|
|
||||
|
4. **计算步骤**： |
||||
|
- 首先计算 \( S \) 乘以12.5，并与2000比较，取较小值作为存储奖励的基础。 |
||||
|
- 然后，计算一个额外的项，这个项的计算包括一个固定值（1/10）和一个动态值，动态值取决于存储容量的计算结果，确保不低于10的值。 |
||||
|
|
||||
|
5. **综合评估**： |
||||
|
- 将所有这些因素结合在一起，得到最终的存储奖励 \( M_S \)。这个值综合考虑了存储容量、网络稳定性和用户在线状态，为奖励的发放提供了依据。 |
||||
|
|
||||
|
通过这种方式，我们能够有效评估存储空间的可用性和网络状态，从而在奖励机制中做出公平的决策。 |
||||
|
|
||||
|
#### 奖励上限 |
||||
|
|
||||
|
- 存储容量的奖励上限设定为2000GB。超出部分将不获得额外奖励。 |
||||
|
- 对于存储的奖励，主要依据容量大小，而与硬盘类型（如HDD、Nvme、SATA等）无关。 |
||||
|
|
||||
|
--- |
||||
@ -0,0 +1,4 @@ |
|||||
|
--- |
||||
|
title: 关于 Layer 2 Node |
||||
|
description: "本文档详细描述如何在 DApp 中与以太坊钱包（如 MetaMask）交互，包括连接钱包、获取账户及对数据进行签名的具体方法。" |
||||
|
--- |
||||
@ -0,0 +1,7 @@ |
|||||
|
--- |
||||
|
title: 简介 |
||||
|
description: "本文档详细描述如何在 DApp 中与以太坊钱包（如 MetaMask）交互，包括连接钱包、获取账户及对数据进行签名的具体方法。" |
||||
|
--- |
||||
|
|
||||
|
|
||||
|
|
||||
Write
Preview
Loading…
Cancel
Save
Reference in new issue