From 61b1a76697747bf7dbbbf387039ec1e0ff579ab5 Mon Sep 17 00:00:00 2001 From: dz_sszz Date: Thu, 15 Oct 2026 17:31:42 +0800 Subject: [PATCH 1/3] [teamai] Initialize single-repo mode (skills/rules/docs/learnings skeleton) --- .codex/hooks.json | 84 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 .codex/hooks.json diff --git a/.codex/hooks.json b/.codex/hooks.json new file mode 100644 index 000000000..200394f38 --- /dev/null +++ b/.codex/hooks.json @@ -0,0 +1,84 @@ +{ + "hooks": { + "SessionStart": [ + { + "hooks": [ + { + "type": "command", + "command": "bash -lc \"teamai hook-dispatch session-start --tool codex 2>/dev/null\" || true", + "additionalContextLimit": 0 + } + ] + } + ], + "Stop": [ + { + "hooks": [ + { + "type": "command", + "command": "bash -lc \"teamai hook-dispatch stop --tool codex 2>/dev/null\" || true" + } + ] + } + ], + "PostToolUse": [ + { + "hooks": [ + { + "type": "command", + "command": "bash -lc \"teamai hook-dispatch post-tool-use --tool codex 2>/dev/null\" || true" + } + ] + }, + { + "hooks": [ + { + "type": "command", + "command": "bash -lc \"teamai hook-dispatch post-tool-use --tool codex --matcher Skill 2>/dev/null\" || true" + } + ], + "matcher": "Skill" + }, + { + "hooks": [ + { + "type": "command", + "command": "bash -lc \"teamai hook-dispatch post-tool-use --tool codex --matcher TodoWrite 2>/dev/null\" || true" + } + ], + "matcher": "TodoWrite" + } + ], + "UserPromptSubmit": [ + { + "hooks": [ + { + "type": "command", + "command": "bash -lc \"teamai hook-dispatch prompt-submit --tool codex 2>/dev/null\" || true" + } + ] + } + ], + "SubagentStop": [ + { + "hooks": [ + { + "type": "command", + "command": "bash -lc \"teamai hook-dispatch subagent-stop --tool codex 2>/dev/null\" || true" + } + ] + } + ], + "SubagentStart": [ + { + "hooks": [ + { + "type": "command", + "command": "bash -lc \"teamai hook-dispatch subagent-start --tool codex 2>/dev/null\" || true", + "additionalContextLimit": 0 + } + ] + } + ] + } +} From 19d6af815bf67aaff6cd68ed99da28c93fbf4796 Mon Sep 17 00:00:00 2001 From: dz_sszz Date: Thu, 15 Oct 2026 17:56:38 +0800 Subject: [PATCH 2/3] docs: add TeamAI member guide and diagram skill --- .gitignore | 2 +- .teamai/.gitignore | 34 ++++ .teamai/agents/.gitkeep | 1 + .teamai/docs/baseline/.gitkeep | 1 + .teamai/docs/current/.gitkeep | 1 + ...15\344\275\234\346\211\213\345\206\214.md" | 155 ++++++++++++++++++ .teamai/env/.gitkeep | 1 + .teamai/hooks/.gitkeep | 1 + .teamai/learnings/.gitkeep | 1 + .teamai/mcp/.gitkeep | 1 + .teamai/rules/.gitkeep | 1 + .../skills/document-logic-diagram/SKILL.md | 39 +++++ .teamai/teamai.yaml | 12 ++ 13 files changed, 249 insertions(+), 1 deletion(-) create mode 100644 .teamai/.gitignore create mode 100644 .teamai/agents/.gitkeep create mode 100644 .teamai/docs/baseline/.gitkeep create mode 100644 .teamai/docs/current/.gitkeep create mode 100644 ".teamai/docs/\345\233\242\351\230\237\346\210\220\345\221\230\346\223\215\344\275\234\346\211\213\345\206\214.md" create mode 100644 .teamai/env/.gitkeep create mode 100644 .teamai/hooks/.gitkeep create mode 100644 .teamai/learnings/.gitkeep create mode 100644 .teamai/mcp/.gitkeep create mode 100644 .teamai/rules/.gitkeep create mode 100644 .teamai/skills/document-logic-diagram/SKILL.md create mode 100644 .teamai/teamai.yaml diff --git a/.gitignore b/.gitignore index 460620520..391bdea13 100644 --- a/.gitignore +++ b/.gitignore @@ -18,10 +18,10 @@ __pycache__/ # Local AI tool / agent workspaces (worktrees, scratch state) .claude/ +.codex/skills/ .gstack/ .worktrees/ .codebuddy/ -.teamai/ # TeamAI-managed Copilot sync artifacts .github/hooks/teamai.json .github/skills/ diff --git a/.teamai/.gitignore b/.teamai/.gitignore new file mode 100644 index 000000000..f3b1487fa --- /dev/null +++ b/.teamai/.gitignore @@ -0,0 +1,34 @@ +# teamai single-repo mode — machine-local state (never commit). +config.yaml +config.yaml.*.tmp +state.json +token +teamai.lock +.update-lock +.reports-lock +.learnings-lock +.bootstrap-lock +.sync-lock +env.sh +env.sh.exports.json +env.local +usage.jsonl +usage.jsonl.* +usage.pending-*.jsonl +known-skills.json +search-index.json +managed-mcp.json +workspaces/ +dashboard/ +reports-wt/ +learnings-wt/ +knowledge-wt/ +pending-learnings/ +members/ +sessions/ +votes/ +stats/ +pending-review.jsonl + +# skills/, rules/, docs/, learnings/, env/, agents/, hooks/ and mcp/ +# are shared team resources and are intentionally committed to main. diff --git a/.teamai/agents/.gitkeep b/.teamai/agents/.gitkeep new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/.teamai/agents/.gitkeep @@ -0,0 +1 @@ + diff --git a/.teamai/docs/baseline/.gitkeep b/.teamai/docs/baseline/.gitkeep new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/.teamai/docs/baseline/.gitkeep @@ -0,0 +1 @@ + diff --git a/.teamai/docs/current/.gitkeep b/.teamai/docs/current/.gitkeep new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/.teamai/docs/current/.gitkeep @@ -0,0 +1 @@ + diff --git "a/.teamai/docs/\345\233\242\351\230\237\346\210\220\345\221\230\346\223\215\344\275\234\346\211\213\345\206\214.md" "b/.teamai/docs/\345\233\242\351\230\237\346\210\220\345\221\230\346\223\215\344\275\234\346\211\213\345\206\214.md" new file mode 100644 index 000000000..ef02a8c45 --- /dev/null +++ "b/.teamai/docs/\345\233\242\351\230\237\346\210\220\345\221\230\346\223\215\344\275\234\346\211\213\345\206\214.md" @@ -0,0 +1,155 @@ +# Gitbook 团队成员操作手册 + +这份手册只保留成员日常需要的操作：初始化、开始工作、提交、修改和合并后同步。 + +## 1. 第一次接入 + +### macOS + +```bash +brew install gh +gh auth login --hostname github.com --git-protocol ssh --web +npm install -g teamai-cli + +git clone git@github.com:memoio/Gitbook.git +cd Gitbook +teamai pull +teamai doctor +``` + +如果 GitHub 登录超时，且本机代理端口是 `7897`： + +```bash +export HTTP_PROXY=http://127.0.0.1:7897 +export HTTPS_PROXY=http://127.0.0.1:7897 +gh auth login --hostname github.com --git-protocol ssh --web --skip-ssh-key +``` + +这是单仓库模式，仓库里的 `.teamai/teamai.yaml` 会自动完成本机初始化；成员不要再次执行 `teamai init .`。看到 `All checks passed` 即接入成功。 + +## 2. 每次开始使用 + +进入仓库并同步最新内容： + +```bash +cd /你的路径/Gitbook +git switch main +git pull --ff-only +teamai pull +``` + +然后从这个仓库目录启动 AI： + +- Codex：在 Codex 中把 `/你的路径/Gitbook` 添加为项目，并在该项目中新建对话。 +- Claude Code：在终端执行 `cd /你的路径/Gitbook && claude`。 + +新对话会加载项目中的 TeamAI Skill、Rule 和 Docs。已经打开的旧对话可能没有新资源；合并新 Skill 后应执行 `teamai pull`，再新建对话。 + +## 3. 新增或修改内容 + +先创建自己的分支： + +```bash +git switch -c docs/简短主题 +``` + +常用位置： + +| 内容 | 路径 | +| --- | --- | +| 团队文档 | `.teamai/docs/` | +| 团队 Skill | `.teamai/skills//SKILL.md` | +| 团队 Rule | `.teamai/rules/.md` | +| 当前业务代码或普通文档 | 仓库原有目录 | + +修改完成后检查： + +```bash +git status +git diff +teamai pull +``` + +新 Skill 可在新开的 Codex 或 Claude Code 对话中测试。可以直接说： + +```text +使用 document-logic-diagram skill，把这段文档内容画成逻辑说明图。 +``` + +## 4. 提交修改 + +```bash +git add <本次修改的文件> +git commit -m "docs: 简要说明本次修改" +git push -u origin HEAD +gh pr create --fill +``` + +不要直接把工作分支合并到 `main`。在 GitHub Pull Request 中等待其他成员评审。 + +## 5. 根据评审意见修改 + +继续在原分支修改，不要重新建 PR： + +```bash +git add <修改后的文件> +git commit -m "docs: address review feedback" +git push +``` + +原 Pull Request 会自动更新。重复修改和提交，直到评审通过。 + +## 6. PR 合并以后 + +```bash +git switch main +git pull --ff-only +teamai pull +git branch -d <刚才的分支名> +``` + +如果合并的是新 Skill 或 Rule，关闭旧 AI 对话并从 Gitbook 项目中新建对话。新对话会加载合并后的版本。 + +## 7. 上传初始 Markdown 文档 + +初始原文保存一份不可改的基线，同时复制一份作为后续工作版本： + +```bash +git switch -c docs/import-initial-document +mkdir -p .teamai/docs/baseline .teamai/docs/current + +cp /初始文档的绝对路径/初始文档.md .teamai/docs/baseline/初始版本.md +cp /初始文档的绝对路径/初始文档.md .teamai/docs/current/当前版本.md + +git add .teamai/docs/baseline/初始版本.md \ + .teamai/docs/current/当前版本.md +git commit -m "docs: import initial document" +git push -u origin HEAD +gh pr create --fill +``` + +以后只修改 `.teamai/docs/current/当前版本.md`，不要修改 `baseline/初始版本.md`。初始文档的讨论、修改和确认都通过新的分支与 Pull Request 完成。 + +## 8. 常见问题 + +### AI 看不到新 Skill + +```bash +git switch main +git pull --ff-only +teamai pull +teamai list +``` + +确认 Skill 已列出，然后在 Gitbook 项目中新建 Codex 或 Claude Code 对话。 + +### 查看环境是否正常 + +```bash +teamai doctor +teamai status +``` + +### GitHub 登录超时 + +确保代理软件正在运行，并给终端设置 `HTTP_PROXY` 和 `HTTPS_PROXY` 后重新执行 `gh auth login`。 diff --git a/.teamai/env/.gitkeep b/.teamai/env/.gitkeep new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/.teamai/env/.gitkeep @@ -0,0 +1 @@ + diff --git a/.teamai/hooks/.gitkeep b/.teamai/hooks/.gitkeep new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/.teamai/hooks/.gitkeep @@ -0,0 +1 @@ + diff --git a/.teamai/learnings/.gitkeep b/.teamai/learnings/.gitkeep new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/.teamai/learnings/.gitkeep @@ -0,0 +1 @@ + diff --git a/.teamai/mcp/.gitkeep b/.teamai/mcp/.gitkeep new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/.teamai/mcp/.gitkeep @@ -0,0 +1 @@ + diff --git a/.teamai/rules/.gitkeep b/.teamai/rules/.gitkeep new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/.teamai/rules/.gitkeep @@ -0,0 +1 @@ + diff --git a/.teamai/skills/document-logic-diagram/SKILL.md b/.teamai/skills/document-logic-diagram/SKILL.md new file mode 100644 index 000000000..85e3ed3a4 --- /dev/null +++ b/.teamai/skills/document-logic-diagram/SKILL.md @@ -0,0 +1,39 @@ +--- +name: document-logic-diagram +description: Create or revise document logic diagrams and research-paper-style framework, process, mechanism, or relationship figures. Use when a document needs a clear visual explanation of its logical structure. +--- + +# Document Logic Diagram + +Create the diagram artifact, not only a prompt or layout suggestion. + +## Visual requirements + +- Use a 16:9 landscape canvas. +- Prefer editable SVG. If PNG is required, export exactly 3840 × 2160 pixels. +- Use a pure white background (`#FFFFFF`). +- Use only black (`#000000`) for text, borders, arrows, and connectors. +- Do not use color, gray fills, gradients, shadows, 3D effects, textures, icons, decorative illustration, or decorative borders. +- Use regular rectangles, consistent stroke width, aligned edges, and generous whitespace. +- Keep typography restrained and readable. Use short labels instead of paragraphs inside boxes. +- Use one clear reading direction—normally left to right or top to bottom—and avoid crossing connectors. + +## Logical structure + +Before drawing, identify the figure's single main claim and the smallest set of relationships needed to explain it. Organize the figure around a clear chain such as: + +`input or premise → process or mechanism → intermediate result → final outcome` + +Use grouping only when it clarifies hierarchy or parallel paths. Do not add elements that lack a role in the explanation. + +## Deliverables + +Provide: + +1. The SVG file or 4K PNG file. +2. A concise title or figure caption. +3. A short logic explanation in prose that walks through the diagram in reading order and states how the parts lead to the conclusion. + +## Final check + +Verify the 16:9 ratio, white background, black-only palette, consistent lines, readable labels, sufficient whitespace, absence of overlaps or clipping, and a complete logical path from premise to outcome. diff --git a/.teamai/teamai.yaml b/.teamai/teamai.yaml new file mode 100644 index 000000000..a72241b6d --- /dev/null +++ b/.teamai/teamai.yaml @@ -0,0 +1,12 @@ +team: Gitbook +mode: self +description: TeamAI single-repo for shared documents, skills, rules, and learnings +repo: https://github.com/memoio/Gitbook.git +provider: github +sharing: + rules: + enforced: [] + docs: + localDir: ./.teamai/docs + env: + injectShellProfile: true From 6637f7da7e953faa916b5f30143665ccd8070fdd Mon Sep 17 00:00:00 2001 From: dz_sszz Date: Thu, 15 Oct 2026 18:11:38 +0800 Subject: [PATCH 3/3] docs: import initial document --- ...35\345\247\213\347\211\210\346\234\254.md" | 3189 +++++++++++++++++ ...23\345\211\215\347\211\210\346\234\254.md" | 139 + 2 files changed, 3328 insertions(+) create mode 100644 ".teamai/docs/baseline/\345\210\235\345\247\213\347\211\210\346\234\254.md" create mode 100644 ".teamai/docs/current/\345\275\223\345\211\215\347\211\210\346\234\254.md" diff --git "a/.teamai/docs/baseline/\345\210\235\345\247\213\347\211\210\346\234\254.md" "b/.teamai/docs/baseline/\345\210\235\345\247\213\347\211\210\346\234\254.md" new file mode 100644 index 000000000..229396910 --- /dev/null +++ "b/.teamai/docs/baseline/\345\210\235\345\247\213\347\211\210\346\234\254.md" @@ -0,0 +1,3189 @@ +# MEMO GitBook 完整文档导出（中文版） + +> 来源：https://memolabs.gitbook.io/memo-gitbook/memo-docs-cn +> 导出日期：2026-09-03 +> 说明：本文档按照原 GitBook 侧边栏层级结构（Overview → MEMO Protocol → Tokenomics → Ecosystem → MEMO AIAgent → FAQ → Community）完整整理，标题层级与原站导航一一对应。原文中的图片未能导出，相关位置以说明保留；正文文字、代码块、表格、合约地址等均为完整内容。 + +## 目录 + +- 欢迎 / Welcome +- 一、Overview（概览） + - 1.1 Introducing MEMO（首页 / 简介） +- 二、MEMO Protocol + - 2.1 Data Blockchain + - 2.2 MEMO Protocol（协议总览） + - 2.2.1 Data Storage Layer + - 2.2.2 Computation Layer + - 2.2.3 Verification Layer + - 2.2.4 Execution Layer + - 2.2.5 Identity Layer + - 2.2.6 Smart Layer + - 2.3 Key Features（关键特性） + - 2.3.1 User Centric + - 2.3.2 Decentralized Identity (DID) + - 2.3.3 Data Availability (DA) + - 2.3.4 Data Assets + - 2.4 Getting Started（快速开始） + - 2.4.1 成为存储提供者 + - 2.4.2 使用数据管理服务 + - 2.4.3 申请 DID + - 2.4.4 申请算力资源 + - 2.4.5 使用数据可用性服务 + - 2.4.6 简化与 dApp 的交互 + - 2.4.7 智能合约地址 +- 三、Tokenomics（代币经济学） + - 3.1 MEMO & Deposit + - 3.2 Distribution +- 四、Ecosystem（生态系统） + - 4.1 MEFS + - 4.2 Data Wallet + - 4.3 Data Market + - 4.4 Computing Power Platform + - 4.5 What's Meeda + - 4.5.1 Description + - 4.5.2 Node Type + - 4.5.3 Resource + - 4.6 What is ERC-7829 + - 4.7 ERC7921 +- 五、MEMO AIAgent + - 5.1 Introduction + - 5.2 x402 + - 5.2.1 How x402 Works + - 5.2.2 HTTP 402 + - 5.2.3 MEMO Facilitator + - 5.3 ERC-8004 (Trustless Agents) + - 5.4 Attestation Server (AS) + - 5.4.1 How AS Work + - 5.5 MEFS MCP Server + - 5.6 Elizaos Plugin + - 5.7 MEMO DID（Agent DID 规范） + - 5.8 Detailed Description of Meeda + - 5.9 Lightnode API + - 5.9.1 How to Connect L2 to Meeda + - 5.9.2 Deploy OPStack Layer2 with Meeda + - 5.9.3 Contract + - 5.9.4 FileProof API + - 5.9.5 FileProof Contract Address + - 5.10 How to Build Lightnode + - 5.10.1 Layer2+Meeda + - 5.11 Storage +- 六、FAQ（常见问题） +- 七、Community（社区） + +--- +# MEMO 官方文档库（中文版） + +## 欢迎 + +欢迎来到 MEMO 官方文档库。 + +MEMO 由 MemoLabs 维护。"MEMO 是一个人工智能驱动的去中心化平台，正在彻底改变数据存储和管理。"通过提供安全、智能和以用户为中心的云解决方案，MEMO 使用户能够以前所未有的方式控制他们的数据。 + +这些文档是关于 MEMO 系统架构和生态模块的。 + +### 贡献指南 + +我们欢迎社区参与！请确保为您的更改创建一个新分支，并在提交前提供正确且充分的提交消息。 + +# 一、Overview（概览） + +## 1.1 Introducing MEMO（首页 / 简介） + +随着互联网进入数据爆炸时代，数据的存储、隐私保护和资产化成为关键挑战。传统数据存储方式面临系统故障频发、隐私性得不到保障、以及数据资产化过程复杂且不透明的问题。在区块链技术的快速发展中，数据层的概念提供了解决这些问题的关键思路。 + +MEMO作为一个基于区块链的数据层，具有以下特点： + +解决传统存储的局限性 + +当前的中心化存储方式（如传统云存储）容易受到单点故障和隐私泄漏的影响。MEMO 的设计通过将数据的存储、处理和访问分离，构建了更灵活且去中心化的存储架构，提升了数据存储的安全性和可靠性。 + +提升区块链的可扩展性 + +区块链系统在面对海量数据时常常遭遇性能瓶颈。MEMO 通过数据层架构，使存储功能与执行和共识层分离。这种设计减少了区块链节点的负担，提高了系统的吞吐量，使其能够更好地支持高频交易场景和复杂应用。 + +促进数据资产化与透明性 + +数据资产化是未来数字经济的重要趋势，但传统模式下的流程往往缺乏透明性，且用户对数据的控制权不足。MEMO 借助区块链的可追溯性和透明性，赋予用户对数据使用和共享的控制权，同时简化数据资产化的流程。 + +为Web3构建基础设施 + +数据层是构建 Web3 基础设施的重要组成部分。MEMO 的架构使其能够与其他区块链或应用无缝集成，支持跨链互操作性，为开发者提供灵活的工具来构建去中心化应用。 + +为了实现上述愿景，MEMO构建了由MEMO Protocol组成的生态系统，推出了MEFS分散式存储系统，提供了Meeda和Mooda两个数据可用性解决方案，开发了EthDrive、LensDrive两个链上网盘，并且推出数据钱包、数据交易市场、去中心化算力租赁平台。 + +**MEMO协议** + +MEMO协议是一个数据层，可以促进区块链+AI的数据存储、数据管理和数据资产化。它涵盖分散式数据存储、链上数据存储验证、去中心化身份、用户对数据的百分百管理权、数据轻松资产化。通过MEMO协议，用户能够前所未有地掌控自己的数据，区块链系统在灵活性和数据的可扩展性上能够得到提升。 + +**MEFS** + +MEFS是第一个分散式存储系统，基于区块链，利用闲置边缘存储设备，为用户提供低价格、隐私保护、高可靠性的存储服务。 + +**Meeda** + +Meeda（取MEMO的前两个字母、Ethereum的第一个字母以及数据可用性的缩写DA）是一套针对以太坊生态的数据可用性解决方案，为以太坊Layer2提供低成本、高安全的数据存储和证明服务。 + +**DataDrive** + +MEMO的DataDrive包含Drive3、EthDrive和LensDrive，旨在为Web3应用程序提供高安全性、高容量和用户友好的功能。它基于MEMO的去中心化存储系统MEFS构建，利用区块链技术来确保数据隐私、可靠性和用户所有权。LensDrive专为 Lens 去中心化社交生态而设计，它结合了文件备份、预览、分享等功能，旨在为 Web3 用户提供安全、私密、高效的数据存储服务。Drive3和EthDrive具有更加普遍的适用性。 + +**数据钱包（Data Wallet）** + +数据钱包是一种创新的Web3工具，旨在将数据存储和管理与区块链技术结合。它利用MEMO去中心化存储系统为用户提供安全可靠的数据存储环境，同时让用户完全掌控自己的数据。通过加密和智能合约技术，用户可以便捷地存取数据，进行跨链交互，并确保隐私安全。此外，数据钱包还支持将数据视为资产，实现数据的便捷流转和透明管理，为Web3生态的去中心化应用提供核心支持。 + +**数据交易市场（DataMarket）** + +数据交易市场旨在构建一个去中心化的平台，专注于数据的安全交换和资产化。这一市场基于区块链技术运行，通过分布式存储和智能合约机制，实现数据的高效流转和透明交易。省去了高昂的中介费用，为创作者和消费者提供更加公平、公开的数据资产交易平台。 + +**去中心化算力租赁平台（GRID）** + +GRID 是一个去中心化算力租赁平台，旨在解决计算资源供需不平衡的问题。它通过区块链技术搭建一个开放的市场，允许用户出租闲置的算力资源，同时为需要高性能计算的用户（例如AI模型训练、数据分析和科学计算）提供一个灵活、高效且透明的解决方案。 + +--- + +# 二、MEMO Protocol + +## 2.1 Data Blockchain + +### 什么是Data Blockchain? + +随着互联网的发展，用户数据爆发式的增长，2023年每秒将产生4.2PB数据，其中绝大部分为个人数据。然而目前所有个人的数据均由中心化的平台所有，且中心化平台对于个人数据的管理并不透明，这不仅导致了个人数据的大量泄漏，也导致了个人数据的价值均流向了中心化平台，用户基本上无法从自己的数据中收益。Data Blockchain通过结合去中心化机制以及各种隐私保护机制解决了用户的痛点。 + +Data Blockchain是维护去中心化身份以及数据主权的基石，Data Blockchain不仅为用户同样为用户的数据提供了相应的去中心化身份，并且由用户身份来管理数据身份。这种方式可以扩展数据的使用方式，最大限度地放大用户数据价值。Data Blockchain通过存储证明的方式，可以确保数据主权的完整性，数据主权将完全依附于数据本身而不是可能会无效的链接。这种方式可以确保数据的真实性以及完整性。 + +Data Blockchain支持几乎所有的去中心化系统，确保数据以去中心化，隐私的方式进行访问并进行合理的价值再分配。 + +### Data Blockchain的优势 + +Memo协议中Data Blockchain实现了数据主权和用户身份的绑定并提出了全新的数据管理以及代币化的方法。为用户和企业带来了显著的好处。 + +#### 对于用户 + +- **简单易上手**：通过数据钱包，用户可以像管理其NFT资产一样管理其数据资产。 +- **数据隐私**：通过各类隐私保护机制，可以确保个人数据在其生命周期内的安全和隐私。没有用户的允许，任何组织或个人都无法访问用户的数据. +- **数据主权完整性**：通过额外的证明机制，可以确保链上元数据信息以及链下个人加密数据的完整性。 +- **数据货币化和价值分配**：通过将数据货币化，可以在确保个人数据所有权的情况下让用户享受数据的价值。通过为数据货币化后添加各类数据权限，放大了数据资产的价值。 +- **跨链身份**：在多个区块链中保存同一身份，支持更广泛地参与去中心化生态系统。 + +#### 对于企业 + +- **保障用户隐私数据**：企业访问用户授权数据时，能够确保在访问过程中用户数据不会泄露。 +- **针对特定用户投放广告**：企业可根据用户授权数据进行全面的数据分析，针对特定用户投放广告。 +- **合法合规**：确保所有数据收集、处理和价值分配活动完全符合相关法律和监管框架，让企业有信心负责任、合法地处理用户数据。 + +### 用例和应用 + +#### 数据钱包 + +通过Memo协议中去中心化身份登录数据钱包，用户可以在数据钱包中查看并管理其数据。使用数据钱包，用户可以像访问NFT一样访问其数据资产。此外，用户可以使用数据钱包登录到各类web3应用，并通过共享自己的数据赚取收入。使用数据钱包可以在获取收益的同时保障其数据所有权。 + +#### 社交恢复 + +可以为Memo协议中去中心化身份设置社交恢复的功能，通过可信个人的社交网络恢复对去中心化身份的访问权限。社交恢复方法可以为用户的去中心化身份提供额外的安全性和便利性。 + +#### web3统一身份登录 + +其他web3应用可以集成Memo协议的去中心化身份，允许用户只使用单一的身份即可跨链登录其他web3应用。这种方法让用户无需管理繁复的地址，让用户可以将其身份和数据带入各个平台，确保用户安全、统一的身份体验。 + +#### 链上信誉系统 + +用户可以授权链上信誉系统对其信誉数据进行更改，用户的任何链上或链下行为均会锚定到主链上的信誉系统，在主链上更新用户的分数后，同步更新到其他链上信誉系统。该方案可以确保用户信誉准确且一致，并且用户的任何跨链行为均会影响到其信誉分。 + +#### 精准广告投放 + +广告厂商可以为每一类用户针对性的投放广告，而无需访问用户的私密数据。用户使用统一身份登录平台后，用户可以安全的接收特定的广告，用户可通过查看广告以及点击广告获取收益。该方式可确保用户的信息不会泄露给广告平台，并且能够让用户在广告中获益。 + +#### 数据交易市场 + +使用数据钱包中的去中心化身份登录数据交易市场，随后可在数据交易市场中将数据钱包中数据资产挂牌交易，可以直接售卖所有权，也可以仅售卖读取权等权限。通过上述方式，用户可以将数据的价值转换成收益，并且通过设置多种权限能够放大数据的收益。 + +#### AI训练 + +第三方AI平台可以在数据交易市场中购买用户数据的使用权，并以隐私保护的方式使用用户的数据。该方式可确保用户数据在使用过程中不发生泄露。此外，第三方AI平台通过用户的隐私数据训练的AI服务可以为用户提供个性化的服务。 + +## 2.2 MEMO Protocol（协议总览） + +MEMO协议共分为六层，能够在数据生命周期内保证数据安全和隐私，使用户能够在各个去中心化应用中使用、共享其数据并享受数据带来的价值。 + +- **执行层**：MEMO的执行层是MEMO网络中的关键组成部分，负责处理交易和智能合约的执行。它确保区块链系统中交易的有效性和一致性，并与数据可用性层协同工作，提供所需的数据存取与验证。 +- **身份层**：MEMO的身份层是 MEMO 去中心化生态系统中的关键部分，旨在通过提供安全、高效和跨平台的数字身份解决方案来支持用户数据主权和应用互操作性。 +- **智能层**：MEMO的智能层专注于为现代互联网应用提供分布式、高效、自驱动、低成本的数据托管服务。支持Web 2.0应用平滑迁移到Web 3.0，同时为新兴的Web 3.0应用提供强大的基础设施支持。 +- **数据存储层**：MEMO的数据存储层提供高度灵活且可扩展的数据存储方案，用户可根据数据的重要性选择不同的数据存储方案，确保数据存储安全性。 +- **计算层**：MEMO的计算层采用了可信执行环境（TEE），确保个人数据在私密且高安全的环境中执行计算，并在计算完成后发布TEE证明到链上，保证了数据隐私以及数据安全。 +- **验证层**：MEMO的验证层旨在确保各层均能去中心化、安全且正常的运行中起着至关重要的作用。任何人均可以成为验证者并为MEMO协议的运行提供保障，验证者的工作包括验证TEE证明，验证DA证明等。 + +### 2.2.1 Data Storage Layer（数据存储层） + +#### 数据存储层的构成 + +数据存储层用于为上层协议提供数据访问接口，现有的存储产品包括MEFS，IPFS，GreenField，Arweave等。Memolabs的产品生态中使用自行设计开发的MEFS作为底层存储。 + +#### 关于MEFS + +MEFS为Memolabs自主设计研发的一款分散式存储文件系统，通过各种前沿科技解决了传统存储系统的数据安全性，可靠性，隐私性问题，避免了中心化存储系统的各种弊端，并作为MEMO协议栈的存储基础设施得到应用。 + +下面重点介绍MEFS存储系统的相关设计理念和设计原理。 + +##### MEFS设计背景 + +我们目前所处的信息爆炸时代，每天全球产生成千上万的文档、照片、视频等数据文件。然而，传统的集中式存储方法越来越无法满足市场需求。它成本高昂，其次是安全性不够高，因此区块链分布式存储应运而生。与传统集中式存储相比，区块链分布式存储利用全球各地的闲置电子设备，如闲置的手机、电脑、硬盘等，都可以作为边缘存储节点。区块链去中心化存储的典型特点是去中心化、安全性更高、成本更低，这已经引起了全球资本和技术界的关注。 + +目前，区块链去中心化存储技术仍处于不断探索的阶段。经过不懈努力，MEMOlab开发出了新一代基于区块链的去中心化云存储系统MEMO。与传统区块链相比，MEMO采用了更简洁高效的技术处理方法来保护守护者、提供者和用户的信息和数据，从而确保整个存储系统的成本效益，并使用户获得更好的使用体验。 + +##### MEFS的优势 + +- 去中心化存储。 用户上传源文件后，Memo系统可以将数据分发到多个存储节点，并对外提供统一标准化的接口。当目标用户发起下载请求时，最近的节点通过最近的节点下载片段并完整地提供给用户。网络中提供多个图像或副本，大大提高了访问速度和稳定性。 +- 全球共享。 多个Memo设备可以形成集群效应，实现全球数据共享、统一存储空间管理和云存储平台的自动负载均衡。文件可以跨区域和网络分布，支持整个网络的数据存储和高效使用，按需扩展以满足用户对高速扩展的需求。 +- 数据安全。 数据存储功能是Memo的基石，数据的安全性和可靠性是数据存储功能的基石。Memo的数据隐私政策要求在写入边缘存储设备之前，源客户端的数据必须使用用户密钥进行加密。此外，访问控制机制确保数据可以由其所有者或其维护者和存储协作访问，而不会被其他用户或无关的维护者和存储者访问。 +- 系统可靠性。 Memo确保可靠性的目标是防止用户设备、维护设备或边缘存储设备失败时数据丢失。可以使用复制、擦除编码等数据冗余技术来确保边缘存储设备上存储的数据的可靠性。 +- 原始数据恢复方法 - RAFI。除了数据冗余机制外，数据修复方法也是决定数据可靠性的重要因素。Memo的原始数据恢复方法RAFI用于进一步提高边缘存储设备中存储数据的可靠性。RAFI技术可以优化边缘存储空间，并更多地保证数据的安全性和系统的稳定性。通过实时查询，可以快速发现高风险的数据丢失，有效地缩短数据修复的总时间并提高性能。 + +MEMO是一个基于区块链的去中心化云存储系统。它与一些旨在生产区块的项目不同，这些项目的存储数据量直接与区块的计算能力相关；它也不同于伪去中心化的分布式存储项目，这些项目中的一个或几个节点通常承担"中心节点"的功能。 + +##### 设计意图 + +由于分布式云存储系统部署在低信任度的P2P网络中，没有中央第三方组织负责管理，存储设备大多是用户的闲置边缘设备，而非专用存储服务器。因此，对于这种应用场景，去中心化云存储管理系统首先面临系统管理问题，这些问题分为系统角色管理、存储市场管理、数据维护管理等，而这些管理需求最终是使用智能合约来实现的。因此，智能合约的管理问题也必须得到解决。 + +**1. 系统角色管理：解决角色划分问题** + +根据存储场景和功能的需求，分布式云存储系统中的用户被划分为三类。这三种类型的用户被定义为用户、提供者和守护者。它们在系统中的功能如下： + +- 用户： 使用存储空间，具体来说：上传数据，由系统中的存储节点存储，是系统中存储服务的消费者。 +- 守护者： 负责信息中介和管理功能，具体来说：收集与其连接的提供者提供的存储信息，如提供者提供1T存储空间；收集与其连接的守护者的评价信息，如其诚信度等；根据用户存储需求找到符合要求的提供者，并挑战提供者。 +- 提供者： 提供存储空间，具体来说：为用户提供存储空间，保存用户数据，是系统中存储服务的提供者。 + +**2. 存储市场管理：解决如何实施存储服务的问题** + +MEMO的关键应用是存储服务，因此存储市场管理是必不可少的。在守护者的帮助下，用户找到合适的提供者。提供者提供存储数据的空间和时间。守护者定期挑战存储数据的提供者。如果发现提供者挑战失败，则需要触发数据修复功能。当用户需要数据时，从提供者那里下载。根据这一应用场景，用户需要向提供者支付存储费和下载数据费，并向守护者支付协调管理费。 + +如果用户违反存储规则，如损坏数据并拒绝修复等，需要相应的惩罚机制来维护系统的正常运行。守护者如何在用户和提供者之间匹配；建立存储服务后如何根据价格支付；面对用户下载数据的请求时如何解决这些问题。这些问题统称为存储市场管理的需求，MEMO为此设计了存储时长管理解决方案。 + +**3. 数据维护管理 - 解决数据维护问题** + +分布式云存储系统面临数据维护和管理的需求。用户的数据以对象存储的形式存储在选定的提供者上，相应的守护者将挑战以确保守护者完全正确地保存了数据。然而，这种机制缺乏可信度，所有面对同一用户的守护者可能不诚实并提供虚假的挑战结果。 + +此外，用户的元数据信息存储在相应的守护者上并在守护者之间同步。这可以解决集中式云存储中元数据信息负载不平衡或重复的问题。元数据的正确性以及数据的维护可能会被恶意协商。因此，基于智能合约的去中心化和可信度，与存储数据相关的的重要信息可以存储在智能合约中，以维护数据的正确性。 + +为了维护数据的安全性和完整性，应用了各种主流的密码技术，如对称加密和解密、抗碰撞哈希函数和数字签名技术，以满足严格的数据隐私和完整性要求。密码技术、数据冗余和修复技术将为系统提供足够的灵活性，以容忍各种可能的软硬件故障和小规模恶意攻击，如试图入侵维护、存储和用户设备，从而篡改、破坏或披露数据和信息。同时，MEMO使用经过验证的POW技术，辅以更创新的POS技术，并辅以第三方安全工具，进一步增强系统安全性。 + +#### 智能合约 + +构建大规模去中心化存储系统的关键问题之一是高效管理系统角色及其关系。在分布式云存储系统中，根据不同角色，提供的功能不同，需要保存角色信息以确定用户身份以提供相应功能。传统方法是将用户的角色、地址等信息保存在数据库中，由特定公司管理。在去中心化场景中，根据唯一识别用户的账户地址的特点，使用智能合约来管理系统角色信息。 + +如上所述，系统对角色管理、存储市场管理、数据维护和管理有需求，这些需求最终需要通过智能合约来实现。因此，智能合约管理是实现上述三种管理需求的基础。合约管理将贯穿整个系统的运行。 + +##### 如何调用智能合约？ + +部署智能合约后，用户需要使用合约实例才能调用合约中的方法。合约实例可以通过合约地址构建。对于需要在链上改变状态的某些合约功能，需要特定的用户身份才能调用；而对于获取链上状态信息的合约功能，任何用户都可以调用。因此，系统存在存储和获取合约地址等管理问题。 + +在MEMO系统中，账户首先注册为某个角色，如用户。在此过程中，账户的地址和用户角色将保存在角色智能合约中。当账户上线时，将调用角色智能合约。您可以获得自己的角色，并根据角色获得相应的服务。账户根据自己的存储需求、条件等决定它想在系统中成为某种角色。用户上线后，从角色模块中获取账户的角色信息。 + +不同角色有不同的功能，也需要保存角色信息。传统方法是将用户的角色、地址等信息保存在中央数据库中，由特定公司管理。在MEMO系统的去中心化场景中，基于唯一识别用户的账户地址的特点，使用智能合约来管理系统角色信息。在使用的初始阶段，每个用户的守护者由系统随机匹配。在守护者积累了关于提供者的可用性和可靠性的一定数据后，可以建立评分系统来匹配提供者和用户，这可以大大减少交易时间。 + +需求分析是设计和实施的前提。基于上述管理需求，MEMO设计了多个模块来解决角色划分、存储服务实施数据维护和合约调用的问题。这些都是MEMO系统的坚实基石。 + +#### 角色 + +在MEMO分布式云存储系统中，每个用户可以根据自己需要注册一个角色。系统角色包括用户、守护者和提供者。如果是存储需求方，则注册为用户；如果是设备提供方，则注册为提供者；如果只提供信息管理服务，则注册为守护者。本文将从整个系统运行的角度解释每个角色的设计原则。 + +这三个角色的基本职责如下： + +1、用户：是系统中的存储服务消费者，提出存储需求并上传数据。 + +2、守护者：是系统中的管理协调员，负责信息中介和管理功能。 + +3、提供者：是系统中的存储设备提供者，为用户提供存储空间。 + +在这三个角色中，用户和提供者是存储服务的供需双方，用户也是系统中的最终用户。简而言之，用户使用MEMO系统中的存储空间，守护者为用户找到合适的存储节点，存储节点提供者为用户提供数据存储。守护者相当于中间信息匹配者，为用户提供和提供者提供中介服务。我们可以将守护者理解为招聘平台上的猎头或房地产交易平台上的中介。 + +##### 用户 + +由于系统中的最终用户是用户，因此需要为存储服务支付相应的存储费用，因此每个服务请求都由用户发起。 + +当用户提出存储服务需求时，应包括以下要素：存储空间大小、存储时长；提供者和守护者的数量；以及所需的存储单位价格。 + +因为只有在设置上述参数后，守护者才能检索和匹配相应的存储节点。同时，在去中心化云存储系统中，存储节点越多，数据越安全，但存储节点越多，支付的费用越高。因此，用户需要自己确定存储节点提供者和中间管理者守护者的数量，并需要在成本和数据安全之间找到平衡。 + +用户不仅需要支付存储服务费用，当他们需要从提供者下载数据时，也需要支付下载费用，因为下载操作将给提供者带来流量和设备的消耗。 + +由于用户是最终支付方，系统对这个角色没有设置特别限制，因为如果用户不支付，提供者和守护者将停止服务。但对于其他两个角色，提供者和守护者，系统为他们设置了相应的惩罚措施，将在下文讨论。 + +##### 守护者 + +守护者是系统中重要的中介角色。它承担信息中介和管理功能，并从用户支付的存储费用中提取管理佣金。 + +作为信息中介，其基本功能是匹配信息，即匹配需求方和供需方之间的信息。当用户提出存储需求时，守护者将根据用户的要求找到与其连接的提供者，并匹配合适的存储节点。 + +除了基本的信息匹配外，守护者的管理功能主要体现在参与挑战和触发支付上。守护者定期发起并参与对提供者的挑战。其目的是验证提供者是否完整存储数据，即验证提供者的真伪和诚信。根据挑战结果，我们可以了解每个提供者在这段时间内为用户有效存储了多少和多长时间的数据，这将作为用户后续支付的依据。 + +此外，守护者另一个重要的功能是触发存储费用的支付。支付不是由支付方用户或支付方提供者触发的，而是由中间人守护者触发的。这主要是为了增加系统的公平性。由中间人守护者触发可以减少欺诈行为的概率。 + +**守护者的惩罚机制** + +守护者作为中介，参与系统的管理。虽然它在一定程度上可以解决分布式存储系统存储供需的信任问题，但认为守护者本身可能缺乏诚信，例如不及时挑战存储的数据，不及时触发支付。为了触发支付，MEMO因此为角色设计了惩罚措施。惩罚机制的存在可以在一定程度上确保系统的良性运行和社区的健康发展。 + +因此，系统规定，当账户注册为守护者时，必须质押费用。这个费用可以由账户退还，也可以在账户违反系统规定时扣除。如果账户质押的金额不足，或者没有质押存款金额，那么就没有诚信背书，账户的守护者角色无法建立。关于守护者质押的金额，何时扣除罚款以及扣除多少可以链下确定。 + +通常，当账户严重违反系统规定时，将对账户进行处罚。如果守护者无法按时进行存储数据的空间-时间挑战，同步空间-时间挑战的结果并报告空间-时间挑战的结果很长时间，那么系统将禁止该账户。一旦账户被禁止，它将永远不会再成为守护者。 + +当守护者被禁用时，如果守护者质押的余额不为0，则该余额可以如下处理：归还给账户；转移给部署角色合约的角色管理员；转移给违反系统规定的守护者。其他受影响的账户包括用户、守护者和提供者。 + +##### 提供者 + +提供者是系统中提供存储空间的一方。它为用户提供存储服务，并从用户那里获得支付的费用。提供者上线后，需要说明自己的存储情况，包括可用的存储空间、存储时长和所需的存储单位价格。提供者说明自己的情况后，守护者可以根据用户和提供者的情况匹配，然后将匹配的提供者信息发送给用户，以便用户、守护者和提供者形成一个存储服务。 + +像守护者一样，提供者也有触发支付的功能，只不过守护者触发的是存储费用的支付，而提供者触发的是下载费用的支付。这是因为存储费用的验证需要中间管理者守护者的参与，而下载费用的验证不需要中间管理者的参与。 + +**提供者的惩罚机制** + +上述提到了对守护者的违规行为进行惩罚。对于提供者，系统也设计了奖励和惩罚机制，因为提供者可能会有问题，比如数据损坏但不恢复，长期不响应用户下载数据请求或守护者挑战。这不仅会破坏用户的数据，还会严重影响用户体验。 + +因此，对于提供者角色，在申请角色时也需要质押费用。一旦提供者违反系统规则，系统将触发相应的惩罚来扣除质押的金额。 + +#### 惩罚合约部署者：第三方合约管理员Admin + +从系统设计的角度来看，每个角色都可以在MEMO系统中获得收益。由于用户是最终消费者，惩罚措施主要是针对收集角色，即守护者和提供者，系统角色功能的实现和角色之间的互动是通过智能合约实现的，因此惩罚也是通过智能合约实现的。 + +采用基于合约的惩罚机制的原因是：在低信誉环境中部署的去中心化系统，没有具体的组织决策，实施奖惩，而合约具有所有事先制定的条款和执行流程，并且是在计算机的绝对控制下执行的优势。此外，智能合约编译后部署在区块链上，并由虚拟机执行，区块链上的每个节点都会运行智能合约的过程，因此智能合约的执行过程和执行可以实现分布式监督和仲裁的结果。 + +借助智能合约的这些优势，可以事先在合约中规定提供者和守护者的惩罚机制。对于谁触发智能合约的质押扣除功能的问题，可用的解决方案包括：由用户触发；由守护者触发；由其他提供者触发；或由角色合约部署者触发。系统中的任何角色都不适合触发提供者和守护者的质押扣除功能。原因是他们三个在存储服务中相互关联。提供者通过为用户存储数据获得收入，守护者通过帮助用户挑战验证数据和收集信息获得收入。因此，触发质押扣除功能的权力应该转移到一个无关的第三方，即角色合约部署者，这里称为合约管理员Admin。Admin部署惩罚合约，这也是MEMO系统为了实现公平交易而设计的一种制衡机制。 + +#### MEMO文件系统的节点匹配 + +MEMO系统的核心应用是一个去中心化的区块链。为了在低信任度环境中实现公平交易，系统为每个角色设计了相应的功能，存储需求方（用户）、存储协调方（守护者）、存储提供方（提供者）相互交互，形成一个系统生态系统。本文将详细阐述MEMO系统的节点匹配，即用户如何找到为自己提供存储服务的提供者？ + +##### 用户的需求参数设置 + +用户是系统的最终消费者。每项存储服务都由用户发起，然后守护者和提供者为其提供服务。在角色设计文章中，我们提到当用户提出存储服务要求时，应包括以下元素：存储空间大小、存储时长和提供者和守护者的数量。 + +存储空间大小和存储时长是最基本的参数。至于为什么要选择提供者和守护者的数量，是因为MEMO系统使用对象存储，并且离线维护数据使用数据冗余：多个副本或纠错码，因此存储节点越多，数据越安全。因为一旦存储节点上的数据丢失，其他存储节点可以帮助恢复其数据。在这个去中心化云存储系统中，存储节点越多，所有存储节点中数据损坏或丢失的概率越小。但选择的存储节点越多，用户支付的存储服务费用就越高。因此，用户对存储服务的要求也应包括提供者的数量。用户衡量成本和数据安全问题，并确定存储节点提供者的数量。 + +同样，因为守护者需要及时挑战提供者的空间-时间，即通过数据验证技术，检查提供者正确存储了多少数据和存储时长，多个守护者同意挑战结果，共识结果作为支付提供者存储数据的依据。守护者的数量会影响这项存储服务。原因是：守护者越多，伪造挑战结果的成本越高，所有守护者都离线的概率越低。 + +##### 用户的其他参数设置：信誉值、价格 + +当用户提出存储要求时，除了存储空间、存储时长和提供者及守护者数量的基本参数外，根据具体使用场景，可能还会设置一些其他参数。 + +因为每个提供者的诚信度可能不同，有些提供者可以保证每次都正常存储数据并且可以长时间在线，而有些提供者则不能。因此，根据需要，也可以选择提供者的信誉值，这来自于提供者历史服务的表现。当提供者保证长时间在线并且正常为用户存储数据并积极回应守护者的挑战时，其信誉值会更高。信誉值越高，未来与用户匹配的机会就越大。 + +同样，对于守护者，除了数量要求外，信誉值也会涉及。用户在设置参数时也可以要求守护者的信誉值，因为每个消费者都希望与信誉高的合作伙伴合作。 + +此外，系统应为用户提供指定存储服务价格的功能，例如为每1MB数据的每天存储支付多少钱。具体的存储单位价格可以根据系统的实际使用情况确定。 + +总之，用户在寻求存储服务时需要指定的参数包括存储空间大小、存储时长、存储单位价格、守护者参数要求（如守护者数量）和提供者参数要求（如提供者数量）。 + +##### 智能合约匹配 + +用户设置所需参数后，守护者将根据用户的存储服务要求找到与其连接的提供者，并匹配合适的存储节点。匹配操作的具体情况是：提供者上线后，说明自己的存储情况，应包括：可用存储空间、存储时长和所需的存储单位价格。因此，守护者根据双方的情况匹配，然后将匹配的提供者信息发送给用户。从而，用户、守护者和提供者形成一个存储服务。 + +对于守护者如何根据用户和提供者的存储条件进行匹配的问题，第一个解决方案是：当节点连接时，用户和提供者主动将自己的存储服务相关信息发送给守护者；第二个解决方案是：使用智能合约在链上记录用户的存储要求和提供者的存储条件。当连接到守护者时，守护者直接在链上查看匹配。与这两种解决方案相比，第一个解决方案将增加系统网络的负担，并且后续存储服务缺乏可审核性。第二个解决方案将信息记录在智能合约中，具有分布式监督和不可篡改的特点，只有守护者从链上查询信息不会造成比第一个解决方案更大的网络负担，并且也方便审计，但用户和提供者需要承担部署智能合约的成本。 + +因此，与存储服务相关的各种参数信息将通过智能合约记录，包括用户对存储服务的需求参数和提供者可以提供的存储服务相关参数。可以说，智能合约贯穿整个MEMO系统。 + +### 2.2.2 Computation Layer（计算层） + +Computation & Training Layer可在保护用户私密数据的前提下参与第三方公开的计算或者AI训练任务，并从中获取到一定的奖励，该层基于可信执行环境。可信执行环境是中央处理器中隔离的执行环境，能够确保执行程序以及数据的完整性和机密性，因此能够在不泄露用户数据的前提下获得预期的结构。此外，可信执行环境还提供远程认证功能，远程认证功能允许TEE节点生成计算环境报告并提交上链，从而允许验证节点验证计算结果的正确性以及计算环境的私密性。 + +#### 可信执行环境 + +在数据的生命周期内（数据存储，数据传输以及数据使用），我们可以通过端对端加密为数据存储和数据传输提供保护。但是在使用数据计算之前，必须将加密数据解密后才能处理数据。这将导致用户的个人数据对他人可见，不可避免的导致用户数据泄露。可信执行环境为数据使用提供隐私保护 + +可信执行环境，例如Intel SGX，通过一套CPU指令能够为应用创建安全区Enclave——RAM 内的私有硬件加密区域，其中包括可信代码以及数据。除了Enclave内的可信代码外，其余应用包括操作系统以及BIOS均无法访问这部分加密数据。Intel SGX允许Enclave内的可信代码和Enclave外的不可信代码相互调用，但应尽量将可信代码和不可信代码之间的交互次数降至最低。 + +Intel SGX 可针对已知的硬件和软件攻击提供以下保护措施： + +- 安全区内存不可从安全区外读写，无论当前的权限是何种级别，CPU 处于何种模式。 +- 产品安全区不能通过软件或硬件调试器来调试（可创建具有以下调试属性的安全区：该调试属性支持专用调试器，即Intel SGX 调试器像标准调试器那样对其内容进行查看。 此措施旨在为软件开发周期提供辅助，但调试属性的安全区不能用于产品发布）。 +- 安全区环境不能通过传统函数调用、转移、注册操作或堆栈操作进入。调用安全区函数的唯一途径是完成可执行多道保护验证程序的新指令。 +- 安全区内存采用具有回滚保护功能的行业标准加密算法进行加密。访问内存或将 DRAM 模块连接至另一系统只会产生加密数据。 +- 内存加密秘钥会随着电源周期（例如，启动时或者从睡眠和休眠状态进行恢复时）随机更改。 该秘钥存储在 CPU 中且不可访问。 +- 安全区中的隔离数据只能通过共享安全区的代码访问。 + +#### TEE集群 + +memo协议运行了一组TEE集群，TEE节点需要质押一定的memo代币才能参与计算或者AI训练，完成计算后会将结果和证明上传到链上。验证节点会验证链上的证明，验证通过即为TEE节点发放奖励，验证不通过则会扣除TEE节点质押的memo代币。 + +用户若想参与计算或者AI训练，需要用户授权1个或者多个TEE节点访问用户加密数据的权限，并可将其授权的TEE节点作为用户的个人代理服务器。若第三方需要获取用户数据进行计算或者AI训练，只需要访问授权的TEE节点即可，这样做用户无需一直保持上线状态。 + +第三方例如AI公司在发布任务并支付费用后（包括用户，TEE节点以及验证节点的费用），可以直接和相应的TEE节点交互，传入其AI训练参数并由TEE节点获取用户数据并进行AI训练。这样做既保护了用户数据的隐私，也保护了AI公司的AI模型参数的隐私。 + +### 2.2.3 Verification Layer（验证层） + +任何人都可以运行验证节点，以确保MEMO协议以去中心化且安全的运行，我们认为验证节点越多MEMO协议越安全。验证节点需要完成的任务包括：验证TEE认证结果，验证DA证明，验证零知识证明。MEMO的DA证明还支持链上验证。 + +#### TEE认证结果验证 + +在计算层中TEE节点完成计算后，TEE节点需要将计算结果以及TEE认证结果一并发布到链上，并由验证节点订阅链上证明并验证链上证明后，该计算结果才是有效的。 + +#### DA证明 + +在数据存储层中，当用户提交数据至Meeda的存储节点后，Meeda存储节点需要定期生成数据的可用性证明并聚合后发布到链上。Meeda采用乐观证明的机制，仅当验证节点发现存储节点生成的可用性证明有误时，验证节点会对存储节点发起挑战，要求其生成进一步的证明，并最终由链上合约验证证明的有效性。 + +#### 零知识证明（Zero-Knowledge Proof） + +MEMO 采用 zk-SNARK 的 Plonk 协议，并结合 KZG（Kate Polynomial Commitment） 作为验证机制，同时在以太坊的可信设置（trusted setup）中额外引入随机性，进一步提升了系统的安全性和灵活性。 + +通过对以太坊的可信设置添加额外的随机性，MEMO 的验证机制有效降低了单一可信设置中的潜在信任假设风险。即使原始可信设置中某些参数泄露，额外的随机性提供了额外保护。 + +Plonk 本身是一种通用、高效的 zk-SNARK 协议，支持较少的验证器和更快的证明生成。结合 KZG，可以进一步优化零知识证明的性能，在存储和计算资源的使用上更具优势。 + +采用 Plonk 的泛用性，使 MEMO 可以支持各种数据层中的复杂计算需求，而无需为每个具体场景重新构建证明机制。KZG 承诺方案提供了更高效的多项式承诺验证，特别适用于大型去中心化数据系统。 + +通过引入 zk-SNARK 的 Plonk 协议和 KZG 作为验证机制，并在以太坊可信设置上额外添加随机性，MEMO 提升了系统的安全性、效率和去中心化程度。这不仅优化了数据层的验证流程，也为更广泛的去中心化应用提供了高效、安全的基础设施支持。 +### 2.2.4 Execution Layer（执行层） + +**MEMO 的执行层** 是 MEMO 网络中的关键组成部分，负责处理交易和智能合约的执行。它确保区块链系统中交易的有效性和一致性，并与数据可用性层协同工作，提供所需的数据存取与验证。 + +执行层可以支持并优化无中介数据交易和数据资产交换。它使得跨多个区块链网络的数据提供者能够共享他们在各自链上拥有的数据，并能够便利地将数据资产化。 + +MEMO执行层的核心功能包括在链上处理结算信息、记录数据存储的元数据信息、数据验证相关信息、数据资产信息以及去中心化身份信息，并且在验证者之间达成共识后，能够向系统质押者分配奖励，为系统参与者提供丰富的服务。执行层需要针对部分服务提供者收取质押锁定费用，确保服务的安全可靠。 + +通过MEMO Meegrez，执行层增强了链上交易的可扩展性、安全性，降低了交易成本。MEMO 的执行层是 MEMO 生态系统的重要组成部分。 + +Meeda 作为 MEMO 的数据可用性服务（Data Availability Service），在 MEMO 的模块化架构中，提供了执行层与数据可用性层之间的通信通道，确保数据可以被执行层顺利读取和验证。执行层需要对交易和计算相关的数据进行验证，Meeda 确保数据的完整性和可用性，为执行提供可信的数据基础。通过将数据可用性工作外包给 Meeda，执行层专注于计算和逻辑处理，大幅提升整体性能。Meeda 提供快速的数据检索和验证服务，减少执行层的数据访问延迟，优化交易确认速度。Meeda 的存在，使 MEMO 的执行层可以灵活地与不同的模块交互，而无需直接处理底层数据存储和验证的复杂性。 + +在 MEMO 的执行层中，Meeda 不仅保障了数据的可用性和完整性，还通过高效的数据交互支持了执行层的快速运转。它的存在使模块化数据层的架构更加灵活，确保了 MEMO 系统在去中心化生态中高效、安全地运行，同时为 Web3 应用提供了可靠的基础设施。 + +### 2.2.5 Identity Layer（身份层） + +Identity Layer 是 MEMO 去中心化生态系统中的关键部分，旨在通过提供安全、高效和跨平台的数字身份解决方案来支持用户数据主权和应用互操作性。 + +MEMO 通过整合账户 DID（memo did）、文件 DID（mfile did） 和设备 DID（mdevice did） 构建了一个创新的 Identity Layer（身份层），为去中心化数据生态提供了全面而高效的身份管理和认证解决方案。 + +在数据层中，用户、设备、文件等实体需要拥有唯一的身份标识，以避免数据冲突或虚假身份。传统系统通常依赖中心化服务进行身份认证，而数据层中，Identity Layer 以区块链为基础，消除了对中心化认证服务的依赖。 + +Identity Layer 赋予每个数据对象（如文件、交易记录）唯一的标识（如文件 DID），支持对数据的存储、共享和资产化管理。数据交易需要明确所有权和访问权限，Identity Layer 确保交易过程透明、数据来源可信，避免资产纠纷。 + +数据层中，数据存储和访问需要基于身份的细粒度控制，例如允许特定用户或设备访问特定数据。Identity Layer 提供了动态调整权限的机制，支持更复杂的场景需求。通过加密与选择性披露功能，用户可以根据需要分享身份信息或数据，同时保护敏感信息。 + +数据层不仅处理数据，还涉及用户与设备的协作。Identity Layer 提供账户 DID、文件 DID 和设备 DID，分别管理用户身份、数据文件和物联网设备，形成高效协作的生态。Identity Layer 遵循 W3C DID 标准，与其他模块或外部系统实现无缝对接，扩大了数据层的应用范围。 + +数据层中的治理通常依赖于去中心化自治组织（DAO）。Identity Layer 确保每个参与者拥有独立可信的身份，绑定治理权利，如投票或提案。通过链上记录和身份验证，所有治理活动都具有可追溯性，增强去中心化生态的透明度。 + +除此之外，Identity Layer还支撑物联网和边缘计算场景。Identity Layer 通过设备 DID 提供统一的身份管理方案，支持设备接入、数据共享和远程控制。通过区块链和设备 DID，设备间可以实现安全的数据交换，无需依赖中心化服务器。 + +#### 账户DID + +账户 DID（Decentralized Identifier） 是 MEMO 生态系统中管理用户身份和数据的关键模块。账户 DID 的作用主要体现在以下几个方面： + +1. 去中心化的身份管理 + - 唯一标识：账户 DID 为每个用户生成一个唯一的标识符，确保身份在 MEMO 网络及其兼容的 Web3 平台中可被准确识别。 + - 数据自主权：用户完全掌控自己的 DID，能够独立管理身份和关联数据，摆脱传统中心化系统对身份数据的垄断。 +2. 跨平台身份互操作性 + - 兼容性：账户 DID 遵循 W3C 的 DID 标准，与其他区块链网络和 DApps 实现互操作性，用户可以用同一个 DID 在多个平台上无缝登录和操作。 + - 统一管理：通过一个 DID，用户可以管理与其身份相关的所有活动，减少多重账户带来的复杂性。 +3. 数据隐私和选择性披露 + - 隐私保护：用户可以选择性地披露部分身份信息给特定的 DApp 或平台，而无需共享全部数据，从而保护隐私。 + - 加密验证：通过公钥加密机制，DID 数据在分享过程中始终保持安全，避免敏感信息被未授权访问。 +4. 支持去中心化数据经济 + - 数据资产化：账户 DID 结合数据存储模块（如 ETHDrive）和数据交易市场，使用户能够将自己的数据进行标记和交易，确保资产所有权和交易透明。 + - 授权存取：DID 与智能合约结合，可细粒度地管理数据访问权限，确保只有授权用户才能存取数据。 + +#### 文件DID + +文件 DID（Decentralized Identifier） 是用于管理文件身份和访问权限的重要工具，旨在确保文件的安全性、可追溯性以及去中心化的存储管理。它在 MEMO 的数据生态系统中发挥了以下几个关键作用： + +1. 唯一文件标识 + - 文件唯一性：每个文件都通过文件 DID 获得唯一的标识符，确保在整个网络中能够唯一识别和区分。 + - 去中心化存储：文件 DID 与 MEMO 的存储系统（如 EthDrive 或 MEFS）集成，使文件可以被安全地分布式存储，而不依赖中心化的存储服务。 +2. 文件的可追溯性 + - 链上记录：每个文件的创建、修改、共享记录都会通过文件 DID 在区块链上进行不可篡改的记录，提升透明度和可信度。 +3. 数据访问权限管理 + - 细粒度权限控制：文件 DID 结合智能合约，可实现精确的权限管理。例如，文件拥有者可以通过文件 DID 授予特定用户查看、下载或编辑文件的权限。 + - 动态授权：文件 DID 支持灵活的权限调整，允许文件拥有者根据需要动态更改访问规则。 +4. 数据资产化与交易 + - 数据资产标记：通过文件 DID，文件可以被标记为特定的数据资产，并在 MEMO 的数据交易市场中进行交易。 + - 交易安全：文件 DID 确保数据交易的真实性和透明性，同时通过加密技术保护文件内容不被未授权用户获取。 +5. 跨平台互操作性 + - 标准化兼容性：文件 DID 遵循去中心化标识符标准，与其他区块链和 Web3 平台兼容。用户可以通过文件 DID 在不同平台上共享文件，确保互操作性和使用便捷性。 + - 数据流通性：文件 DID 使文件数据能够安全、高效地在不同的去中心化网络之间流通。 +6. 增强文件安全性与隐私保护 + - 数据加密：文件 DID 配合加密机制，确保文件内容在存储和传输过程中的安全性。 + - 访问隐私：通过文件 DID，文件拥有者可以实现隐私友好的数据共享，只向授权用户披露文件内容。 + +#### 设备DID + +设备 DID（Decentralized Identifier） 是专为设备管理和身份认证设计的去中心化标识符，赋予设备唯一的身份，并在去中心化网络中实现设备间的互联和数据共享。设备 DID 的作用主要体现在以下几个方面： + +1. 唯一设备标识 + - 去中心化的唯一身份：每个设备通过设备 DID 获得一个唯一标识，无需依赖中心化服务器即可在网络中识别。 + - 防止设备伪造：设备 DID 通过链上存储和加密技术确保标识的真实性，防止设备身份被伪造或篡改。 +2. 安全的设备认证 + - 设备可信性验证：设备 DID 与区块链中的公钥机制结合，可进行设备身份的加密验证，确保设备接入的安全性。 + - 分布式信任体系：通过去信任化的方式，设备可以在无需依赖中心化认证机构的情况下参与网络交互。 +3. 数据共享与协作 + - 高效设备间通信：设备 DID 为设备提供了一种标准化的通信方式，使其能够在去中心化网络中无缝交换数据。 + - 设备授权访问：通过设备 DID 和智能合约，可以为不同设备设置精确的数据访问权限，确保数据共享的安全性和隐私性。 +4. 支持物联网（IoT）场景 + - IoT 网络管理：设备 DID 非常适合应用于物联网生态中，提供设备的身份标识、数据传输加密和权限管理功能。 + - 去中心化控制：传统物联网系统依赖中心化服务器，而设备 DID 通过区块链实现分布式管理，提升网络的抗风险能力。 +5. 数据追溯与设备管理 + - 设备活动追踪：设备 DID 记录设备的运行状态和交互历史，使得设备的活动在区块链上可以追溯，提升透明度。 + - 去中心化设备更新：通过设备 DID，可以对设备进行去中心化的固件升级和功能更新，减少依赖中心化服务器的风险。 +6. 跨生态系统互操作性 + - 兼容性：设备 DID 遵循去中心化标识符标准，能够与不同的区块链网络和去中心化应用（DApps）无缝协作。 + - 设备身份的多平台支持：无论是 MEMO 的生态内部，还是其他兼容网络，设备 DID 都能确保设备身份的互认和使用。 + +MEMO 的账户 DID、文件 DID 和设备 DID 在 Identity Layer 的集成应用，打破了传统身份管理的局限，提供了灵活、高效且安全的解决方案。这不仅推动了数据资产化和去中心化治理，还在物联网、数据经济和 Web3 应用中释放了巨大的潜力。 + +Identity Layer 是数据层的核心组件，它确保用户、数据、设备在去中心化网络中的身份真实、权限明确和交互高效。通过提供唯一标识符、动态权限控制和隐私保护机制，Identity Layer 不仅提升了数据层的灵活性和安全性，还为 Web3 应用、物联网和去中心化治理提供了关键支持。这种身份管理方式为数据层的广泛应用奠定了基础。 + +### 2.2.6 Smart Layer（智能层） + +#### 介绍 + +Smart Layer是一个创新的Web 3.0云存储平台，专注于为现代互联网应用提供分布式、高效、自驱动、低成本的数据托管服务。我们的目标是构建一个桥梁，帮助Web 2.0应用平滑迁移到Web 3.0，同时为新兴的Web 3.0应用提供强大的基础设施支持。 + +#### 登录选项 + +为了满足不同用户的需求，Smart Layer提供了灵活的登录方式，包括： + +- **钱包登录**：用户可以直接使用他们的加密货币钱包进行登录，享受便捷的访问体验。 +- **DID登录**：去中心化身份（DID）登录为用户提供了更高的安全性和隐私保护。 + +#### 存储 + +Smart Layer提供了多样化的存储解决方案，以满足用户的不同需求： + +- 用户可以根据自己的需求，将数据上传并存储到基于BTC的Mooda、基于ETH的Meeda、IPFS或者MEFS等分布式存储网络上。 +- 这些存储选项不仅提供了数据的高可用性和持久性，还确保了数据的安全性和隐私性。 + +#### 网关 + +Smart Layer的网关是连接用户和分布式网络的关键组件： + +- 我们的网关利用全球分布的节点，实现了对BTC、ETH等分布式网络的无缝连接。 +- 使得用户可以轻松地与这些网络交互，无需担心复杂的技术细节。 + +#### 付费 + +Smart Layer提供了灵活的付费模式，以适应不同用户和应用的需求： + +- **单次付费**：用户可以在每次文件上传时选择单次付费，这种模式适合偶尔需要存储服务的用户。 +- **订阅付费**：用户也可以选择通过购买一段时间（月、季度、年）的存储空间来付费，这种模式适合需要持续存储服务的用户，提供了更经济的解决方案。 + +## 2.3 Key Features（关键特性） + +本章主要介绍MEMO协议的特征。 + +- **User Centric**：MEMO协议以用户为中心，其设计和运行机制始终将用户的权益、体验和数据主权放在核心位置。 +- **Decentralized Identity**：由MEMO协议提供的去中心化标识符，使用户能够完全控制自己的身份和数据，同时与去中心化平台无缝交互。 +- **Data Availability**：由MEMO协议提供的模块化数据层，持续提供数据可用性证明，用于链上数据发布。 +- **Data Assets**：由MEMO协议提供的链上数据资产，完全释放数据价值。利用Data Availability确保链上链下的一致性以及完整性。 + +### 2.3.1 User Centric（以用户为中心） + +**MEMO 是一个以用户为中心的模块化数据层**，其设计和运行机制始终将用户的权益、体验和数据主权放在核心位置。以下是 MEMO 的核心理念： + +**1. 数据主权归用户所有** + +- **用户控制权**：在 MEMO 的模块化数据架构中，用户对自己的数据具有完全的控制权。用户可以决定如何存储、共享和交易数据，而不需要依赖于中心化平台。 +- **隐私保护**：通过加密和去中心化的设计，用户的数据访问和共享仅在授权的情况下进行，确保数据隐私和安全。 + +**2. 经济权益归用户** + +- **数据资产化**：MEMO 提供了数据交易市场，让用户能够将自己的数据进行透明、安全的交易，从中获取经济价值。 +- **收益分配**：用户不仅是数据的所有者，还可以通过参与网络（如存储节点或数据贡献）获得奖励，从而在生态中直接受益。 + +**3. 灵活与便捷的用户体验** + +- **模块化架构**：MEMO 的模块化设计允许用户根据需求选择特定功能模块，如存储（MEFS、ETHDrive、LensDrive）、计算（Grid）、数据管理（Data Market、Data Wallet），减少冗余复杂性。 +- **跨平台兼容性**：基于 MEMO 的 DID 和去中心化协议，用户可以轻松在不同的 DApps 和 Web3 平台间操作，避免多重身份管理的困扰。 + +**4. 支持用户参与治理** + +- **去中心化治理**：MEMO 网络通过 DAO 以及其他治理机制，赋予用户决策权，使其能够直接参与平台的发展规划和规则制定。 +- **透明度和信任**：所有治理流程公开透明，用户能够了解并影响网络的运营。 + +**5. 降低使用成本** + +- **优化费用**：通过模块化设计和高效的网络运行，MEMO 将存储和数据处理成本降到最低，减轻用户的经济负担。 +- **多样化服务**：MEMO 提供不同层级的服务，用户可以根据自己的需求选择经济高效的方案。 + +MEMO 是以用户为中心的，因为它让用户在数据的存储、管理、交易和使用中占据主动地位，保护用户隐私并提升使用体验，同时通过经济激励和治理参与使用户成为网络生态的核心驱动力。 + +### 2.3.2 Decentralized Identity (DID) + +DID (Decentralized Identifier) 是一种基于分布式账本或其他去中心化技术的标识系统，用于识别个人、组织、物品或实体。DID 是去中心化身份（Decentralized Identity）的核心技术，与传统中心化的身份管理方式不同，DID 由用户自己掌控，并不依赖于中央权威机构或中介平台。 + +**DID 的核心特性** + +去中心化：DID 不依赖于任何中央机构，用户拥有对自己身份数据的完全控制权。 + +安全性和隐私性：通过加密技术保护用户数据，只有经过用户授权，身份信息才会共享。 + +全球唯一性：每个 DID 都是独一无二的，不依赖于特定的服务提供商。 + +互操作性：DID 可以在不同的系统和平台之间使用，兼容多种区块链和分布式网络。 + +**DID 的重要性** + +赋权于用户：传统身份管理通常由中央机构或服务商掌控，用户无法完全控制自己的身份数据。DID 通过分布式架构，将数据管理权还给用户。 + +解决身份滥用和欺诈问题：DID 通过密码学方法，确保身份信息的真实性和不可篡改性，有效防止假冒和欺诈行为。 + +支持 Web3 和去中心化应用：DID 是构建去中心化网络和应用的重要组成部分，推动了去中心化自治组织（DAO）、DeFi 和元宇宙的发展。 + +隐私保护：用户可以选择性地共享身份信息，只暴露必要的数据，从而最大程度保护隐私。 + +**MEMO DID** + +MEMO DID是一套去中心化标识系统，提供用户自主、安全和隐私保护的数字身份管理方式。在 MEMO 生态中，DID 的作用集中于身份认证和跨平台互操作性。 + +*MEMO DID 的核心作用* + +数据主权与隐私保护：用户通过 MEMO DID 完全掌控自己的数据，不依赖任何第三方。通过加密技术，用户可以选择性共享数据，确保隐私性和安全性。 + +身份认证与访问控制：用户可以用 MEMO DID 登录去中心化应用（DApps）、访问存储服务或参与数据交易。提供基于身份的访问控制，确保数据仅由授权方使用。 + +跨平台互操作性：MEMO DID 采用开放的去中心化身份标准，支持与其他区块链或系统互操作，实现用户身份的无缝迁移和共享。在 Web3 生态中，DID 可作为统一身份认证桥梁，简化多平台操作。 + +*实际应用场景* + +去中心化存储访问：使用 MEMO DID 认证身份，访问区块链中的存储服务（如 LensDrive）。 + +数据交易与溯源：在数据市场中验证用户身份，确保交易合法透明。 + +Web3 登录认证：用 MEMO DID 替代传统密码或社交账号，实现安全登录。 + +数据共享与合作：通过 DID 授权，将数据安全地共享给特定用户或应用。 + +MEMO DID 是 MEMO 网络的重要组成部分，不仅为用户提供去中心化的身份管理，还增强了数据隐私和交易透明度，为 Web3 生态和去中心化数据处理奠定了基础。 + +### 2.3.3 Data Availability (DA) + +DA（Data Availability，数据可用性） 是区块链技术中的一个关键概念，尤其是在以太坊生态日益蓬勃发展的情况，DA的重要性更加凸显。DA 指的是确保链上的交易数据对所有节点公开和可验证。DA 是保障区块链安全性、去中心化和可扩展性的重要基础。 + +**当前以太坊 DA 的核心机制** + +数据可用性声明：当一个区块生成时，验证者需要确保区块中的所有数据都对网络中其他节点公开，并能够通过验证。 + +数据可用性采样：为减少存储负担，以太坊计划使用像 Proto-Danksharding（EIP-4844）这样的技术，使节点通过采样小部分数据来推测整个区块的数据是否可用。 + +扩展性解决方案的支持：DA 技术与以太坊二层扩展解决方案（如 Rollups）密切相关，后者依赖 DA 提供的数据保障。 + +**DA 的重要性** + +保障安全性：如果数据不可用，网络将无法正确验证交易或证明正确性，可能导致攻击或欺诈行为。 + +支持扩展性：DA 技术通过减少全节点的存储压力，支持以太坊网络实现更高的交易吞吐量。 + +增强去中心化：数据可用性优化允许轻量级节点参与网络，使更多用户能够运行验证节点，从而增强网络的去中心化。 + +与L2解决方案协作：Rollups（如 Arbitrum 和 Optimism）依赖以太坊的数据可用性来确保链下计算的安全和正确性。 + +以太坊 DA 的重要性在于它不仅确保了当前区块链的安全和运行稳定性，还为未来扩展和去中心化奠定了坚实的基础，使以太坊成为更高效的全球计算平台。 + +**Meeda** + +Meeda 是 MEMO 提出的以太坊数据可用性（DA）解决方案，旨在支持以太坊及其 Layer 2 扩展生态。作为一种模块化数据可用性层，Meeda 提供高效、安全且成本较低的数据存储与验证功能。 + +核心特色： + +1. **安全与可靠**：利用加密技术（如 KZG 承诺）和随机验证机制，保障数据的完整性和可用性。 +2. **模块化设计**：将数据存储、验证和可用性功能分离，提高灵活性。 +3. **高可扩展性**：通过分布式存储节点和轻量级验证节点，支持大规模数据存储和访问需求。 +4. **低成本**：优化数据提交和验证流程，降低以太坊网络上的交易费用，适合大规模 Layer 2 生态扩展。 +5. **去中心化参与**：任何用户均可部署节点，成为存储和验证网络的一部分。 + +通过这些功能，Meeda 不仅解决了 Layer 2 数据可用性问题，还增强了整个以太坊生态的扩展能力和用户体验。 + +### 2.3.4 Data Assets（数据资产） + +Data Assets是基于ERC-3130协议的新型资产，用于管理个人数据。通过将个人数据资产化后，能够在确保数据主权的同时释放数据的真实价值。 + +**Data Assets的特性** + +- **数据隐私**：通过各类隐私保护机制，可以确保个人数据在其生命周期内的安全和隐私。 +- **数据主权完整性**：通过额外的证明机制，可以确保链上元数据信息以及链下个人加密数据的完整性。 +- **数据价值完全释放**：通过将数据货币化，可以在确保个人数据所有权的情况下让用户享受数据的价值。通过为数据货币化后添加各类数据权限，放大了数据资产的价值。 + +**Data Assets的重要性** + +- **赋权于用户**：结合去中心化技术，将数据资产的主权赋予用户。用户有权对数据进行任何更新以及权限转移。 +- **解决数据孤岛问题**：集合去中心化技术，数据将可以在多个去中心化系统中流通，共享甚至产生更多更有价值的新数据。 +- **隐私保护**：采用各类隐私保护技术，确保用户数据在其生命周期内仅对用户以及用户授权的实体可见，无论是在数据存储、数据传输、数据使用时。 +- **支持各类去中心化应用**：数据是各类去中心化系统的基础，Data Assets可以支持任意去中心化应用。 + +## 2.4 Getting Started（快速开始） + +本章将介绍MEMO协议的各个项目，以及如何参与和使用这些项目。 + +- **MEFS**：MEFS是一个围绕区块链构建的大规模去中心化数据存储系统，具有高安全性和可靠性。目前可以通过成为Provider并提供存储资源加入MEFS。 +- **Data Management Services**：Data Management Services为web 3.0用户提供数据管理、共享以及代币化方式。包括Data Storage，Data Wallet以及Data Market应用。 +- **DID**：DID (Decentralized Identifier) 是一种基于分布式账本或其他去中心化技术的标识系统，用于识别个人、组织、物品或实体。目前提供由golang语言以及javascript语言编写的SDK。 +- **Computing Resources Services**：Computing Resources Services是一个去中心化的算力平台，用于个人用户训练个性化的智能AI助手。结合POW以及TEE技术，能够确保算力环境真实性以及用户数据隐私。 +- **Data Availability Services**：Data Availability Services为区块链提供数据可用性保证，是模块化区块链不可缺失的一环。目前任何人均可部署验证节点来加入Data Availability Services。 + +### 2.4.1 成为存储提供者（Storage Provider） + +**Docker方式启动Provider的步骤** + +**第 1 步：Docker 环境准备** + +安装后确认 Docker 正在运行。 + +```shell +service docker start +``` + +**第 2 步：设置主目录** + +设置节点主目录（以 "~/memo_provider" 为例）： + +```shell +export MEFS_PATH=~/memo_provider +``` + +设置节点数据存储目录（以 ~/memo_provider_data 为例）： + +```shell +export MEFS_DATA=~/memo_provider_data +``` + +主目录包含配置文件和其他运行节点所需的文件，存储目录是数据存储的位置。 + +**第 3 步：拉取镜像（提供者）** + +```shell +docker pull memoio/mefs-provider:latest +``` + +**第 4 步：初始化（创建新钱包）** + +执行初始化命令，这将生成您的钱包地址并生成配置文件。 + +```shell +docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest init --password=memoriae +``` + +参数解释：`--password`：输入您的提供者密码，默认为memoriae。 + +**第 5 步：检查钱包地址** + +```shell +docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest wallet default +``` + +参数解释：`wallet default`：获取默认钱包地址 + +**第 6 步：充值** + +启动节点需要 Memo 和 cMemo 两种代币。 + +获取 cMemo 代币，有一个水龙头：https://faucet.metamemo.one/ + +MemoChain 信息： + +- 链 RPC：https://chain.metamemo.one:8501/ +- 货币名称：CMEMO +- 链 ID：985 +- 链浏览器：https://scan.metamemo.one:8080/ + +要为您的钱包获取 Memo 代币，您可以从其他拥有足够 Memo 代币的钱包地址转账一些 Memo 代币。提供者至少需要 30 个 Memo 代币。 + +加入我们的讨论，请使用 Slack 链接：https://join.slack.com/t/memo-nru9073/shared_invite/zt-sruhyryo-suc689Nza3z8boa4JkaLqw + +**第 7 步：修改配置文件** + +```shell +docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest config set --key=contract.version --value=3 + +docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest config set --key=contract.endPoint --value="https://chain.metamemo.one:8501" + +docker run --rm -v $MEFS_PATH:/root --entrypoint mefs-provider memoio/mefs-provider:latest config set --key=contract.roleContract --value="0xbd16029A7126C91ED42E9157dc7BADD2B3a81189" +``` + +**第 8 步：启动节点** + +```shell +docker run -d -p 4001:4001 -v $MEFS_PATH:/root -v $MEFS_DATA:/root/data -e PASSWORD="memoriae" -e PRICE=250000 -e GROUP=3 -e SWARM_PORT=4001 -e DATA_PATH=/root/data --name mefs-provider memoio/mefs-provider:latest +``` + +请确保您的提供者主目录和密码与前一步相同。如果有任何部署问题，请加入部署节点讨论。 + +**检查运行状态** + +*第 1 步：进入 docker 容器* + +```shell +docker exec -it mefs-provider bash +``` + +进入容器后，您可以使用 mefs-provider 命令执行操作。 + +*第 2 步：检查提供者信息* + +```shell +mefs-provider info +``` + +示例输出包含：当前时间、版本信息、网络信息（节点ID、IP、类型、声明地址）、同步信息（状态、同步高度、挑战时代）、角色信息（ID、类型、钱包、余额、已存储数据）、群组信息（EndPoint、合约地址、Fs地址、群组ID、安全等级、大小、价格、守护者/提供者/用户数量）、质押信息（质押、总质押、池中总额）。 + +*第 3 步：声明* + +- 当作为提供者节点参与时，您需要执行声明命令（声明公共网络地址）以实现节点间通信； +- 准备好您的公共网络 ip+端口； +- 注意：在容器内执行命令； +- `mefs-provider info` 命令只有在同步信息显示为 true 后才能执行。尽管不执行此操作也可以成功同步，但将无法与其他节点通信。 + +```shell +mefs-provider net declare /ip4/X.X.X.X/tcp/4007 +``` + +参数解释：X.X.X.X 是您的公共 ip 地址；端口 4007 是您的公共网络端口，映射端口是主机的端口 4001（-p 4001：启动参数中的第一个端口 4001）。 + +**检查网络状态** + +*获取本地节点网络信息* + +```shell +mefs-provider net info +``` + +输出示例：`网络 ID ..., IP [/ip4/10.xx.xx.xx/tcp/18003], 类型：私有` + +*获取节点的网络连接信息* + +```shell +mefs-provider net peers +``` + +*连接到指定节点* + +```shell +mefs-provider net connect /ip4/10.2.x.x/tcp/8004/p2p/12D3KooWAykMmqu952ziotQiAYTN6SwfvBd1dsejSSak2jdSwryF +``` + +**常见错误及解决办法** + +- 错误1：没有链上的交易费。解决方案：检查节点，cMemo 代币余额和 memo 余额。Memo 代币余额必须满足节点启动的最低金额。 +- 错误2：执行反转：在 180 天内不能取消质押。解决方案：节点质押金额需要在最后一次质押后 180 天才能提取。 +- 错误3：如果日志报告元数据和状态文件丢失，您可以执行恢复操作。解决方案： + ```shell + mefs-provider recover db --path /home/mcloud/provider2/.memo-provider/meta + mefs-provider recover db --path /home/mcloud/provider2/.memo-provider/state + ``` + +### 2.4.2 使用数据管理服务（Data Management Services） + +MEMO 向用户提供数据存储、数据分享、数据权限定制、数据资产化等数据管理服务。 + +**Data Storage** + +用户可以通过 MEFS 提供的api、cli、浏览器等方式存储数据，具体请参考 cli-usage、api-usage 文档。 + +此外，MEMO还提供 EthDrive（https://ethdrive.net/）、LensDrive（https://lensdrive.net/）、Drive3（https://drive3.net/）供用户使用。 + +**Data Market** + +目前已经实现了协议和后端，正在进行用户界面的开发，敬请期待。 + +**Data Wallet** + +目前协议初版已经确定，正在进行优化和开发，敬请期待。 + +### 2.4.3 申请 DID（Apply for DID） + +DID规范：did-spec（https://github.com/memoio/memo-did-spec） + +Memolabs关于DID的设计文档：did-design（https://github.com/memoio/did-docs） + +**DID Server** + +DID Server是由Memolabs部署维护的DID服务，详细API介绍见 swagger api（https://didapi.memolabs.org/swagger/index.html）。 + +**go-did** + +go-did是由golang语言实现的SDK（https://github.com/memoio/did-go-sdk），可以支持创建，查询，删除以及修改DID。 + +安装go-did： + +```bash +cd $HOME +### 删除所有的本地依赖库和go-did +rm -rf did-solidity go-did memov2-contractsv2 +### 获取依赖包 +git clone https://github.com/memoio/did-solidity.git +git clone https://github.com/memoio/memov2-contractsv2.git +## 将依赖包切换到最新分支(did-solidity) +cd did-solidity +git checkout meeda-v2.0.0 +cd .. +### 获取go-did +git clone https://github.com/memoio/did-go-sdk.git +### 切换到最新分支 +cd go-did +git checkout meeda-v2.0.2 +cd .. +``` + +更新项目的本地依赖（go.mod）： + +``` +replace ( + github.com/memoio/contractsv2 => ../memov2-contractsv2 + github.com/memoio/did-solidity => ../did-solidity + github.com/memoio/go-did => ../go-did +) +``` + +使用go-did：可根据使用文档（https://github.com/memoio/did-go-sdk/blob/master/README_cn.md）中说明进行操作。 + +**js-did** + +js-did是由JavaScript语言实现的SDK，可以支持创建，查询，删除以及修改DID。 + +安装js-did：需要您从 did-js-sdk（https://github.com/memoio/did-js-sdk#）上下载 + +使用js-did：可根据使用文档（https://github.com/memoio/did-js-sdk/blob/master/README_cn.md）中说明进行操作。 + +### 2.4.4 申请算力资源（Apply for Computing Resources） + +**关于 HashCash** + +先来思考一个问题：如何写一个能消耗对方时间的程序？ + +消耗时间还不简单，休眠一下就可以了：`Sleep(1000)`，这确实消耗了时间，但并没有消耗 CPU。如果对方开了变速齿轮，这瞬间就能完成。 + +不过要消耗 CPU 也不难，写一个大循环就可以了：`for i = 0 to 1000000000 end`，但这和 Sleep 并无本质区别。对方究竟有没有运行，我们从何得知？ + +所以，我们需要一个返回结果 —— 只有完整运行才有正确答案： + +``` +result = 0 +for i = 0 to 1000000000 + result = result + i +end +return result +``` + +通过返回结果，我们就能校验，对方是否完整运行了我们的程序。 + +不过上面这个问题，毕竟还是too simple。小学生都知道，用数列公式就可以直接算出结果，根本不用花时间去跑循环。 + +有什么函数，是无法用公式推测的？也就是说，必须老老实实运行函数，才能得出结果。而找不到一种更快的算法，也能算出相同的结果。 + +显然「单向散列函数」就是。例如，一个经典的问题：`MD5(X) == X` 就无法用公式来解决了。要找出答案，只能一个个试过去，需要大量的时间。 + +但对于验证者，是非常轻松的 —— 只需将收到的答案，计算一次就可判断对错。 + +**Hashcash** + +当然，上面的那个例子太困难了，一时间根本找不到答案。但可以做一些改进，例如只要求结果前几位是 0 就可以：`Hash(X) == "0000......"`，这样 0 的数量越少，满足条件的 X 就越容易找到。 + +同时，为了防止答案重复使用，还可以再增加一个盐值：`Hash(X, Salt) == "0000......"`，盐可以由验证者提供，这样就可以充当一个「问题」。符合条件的 X，则可以当做问题的「答案」，提交给验证者鉴定。 + +这就是所谓的 PoW（Proof-of-Work），一种鉴定对方是否投入计算工作的机制。并且只需花费少量的资源，即可鉴定大量的工作。 + +使用散列函数实现的 PoW，就叫做 Hashcash。现实中比特币使用了类似的原理，它使用了 SHA-256 作为散列函数。有权威的密码学算法作为保障，因此只能暴力穷举，而无法使用投机取巧的方法获得结果，保障了挖矿工作的价值。 + +**Grid 中的 PoW** + +在Grid项目中，我们使用了类似HashCash的技术来实现PoW。 + +以下展示了一个计算hash答案的核心方法，它使用了指定的难度和随机值来计算hash值： + +```c +void runSha256(int diffcult, int index, BYTE *data, size_t len, long long *result, long long n) +{ + int blockSize = 16; + int numBlocks = (n + blockSize - 1) / blockSize; + + sha256_cuda<<>>(diffcult, index, data, len, result, n); +} +``` + +答案基于指定的条件来计算：难度和随机值，并在result参数里返回此答案。 + +难度和随机值由验证器（validator）提供，所有节点均向验证器请求这些参数。计算节点必须尝试获取每次挑战的正确的答案，并发送答案到验证器，以验证此算力挑战是否通过。如果计算节点通过了此算力挑战，则表示此计算节点拥有正确的算力，否则计算节点的算力验证失败，因此不能获取对应的Grid算力收益。 + +### 2.4.5 使用数据可用性服务（Data Availability Services） + +**Meeda** + +*Meeda-node* + +通过源码安装meeda-node包括以下几个步骤： + +1. 删除所有的本地依赖库以及meeda-node，并下载所有的依赖库以及meeda-node： + + ```bash + cd $HOME + ### 删除所有的本地依赖库和meeda-node + rm -rf meeda-node did-solidity go-did memov2-contractsv2 go-mefs-v2 relay memo-go-contracts-v2 + ### 获取依赖包 + git clone https://github.com/memoio/did-solidity.git + git clone https://github.com/memoio/did-go-sdk.git + git clone https://github.com/memoio/memov2-contractsv2.git + git clone https://github.com/memoio/go-mefs-v2.git + git clone https://github.com/memoio/mefs-relay.git + git clone https://github.com/memoio/memo-go-contracts-v2.git + ### 将依赖包切换到最新分支(go-mefs-v2) + cd go-mefs-v2 + git checkout 2.7.4 + cd .. + ## 将依赖包切换到最新分支(did-solidity) + cd did-solidity + git checkout meeda-v2.0.0 + cd .. + ## 将依赖包切换到最新分支(go-did) + cd go-did + git checkout meeda-v2.0.2 + cd .. + ### 获取meeda-node + git clone https://github.com/memoio/meeda-node.git + cd meeda-node + ### 切换到最新分支 + git checkout 2.1.0 + ``` +2. 编译meeda-node： + ```bash + CGO_ENABLED=1 make build + ``` +3. 安装meeda-node： + ```bash + make install + ``` +4. 检查meeda-node是否安装成功： + ```bash + meeda version + ``` + 该命令会输出当前meeda-node的版本信息，commit信息以及编译日期。 + +*下一步：部署meeda-node* + +您已经安装完成meeda-node，现在您需要部署meeda-node从而接入meeda的数据可用性网络。您有以下两种类型的节点类型可供选择： + +- meeda轻节点 +- meeda存储节点，目前仅由memolabs团队部署维护，不开放部署。 + +*Meeda轻节点* + +Meeda轻节点功能：质押成为轻节点；从存储节点访问数据从而生成KZG证明，并提交证明，从而获得收益；验证Meeda存储节点和其他轻节点提交的KZG证明，若验证KZG证明有误，则发起挑战，从而获得奖励，提交错误证明的节点受到惩罚；查询历史总收益额和总罚款。 + +通过Meeda轻节点提供的http接口，用户还可以下载Meeda存储的数据、查看文件相关信息、查看证明信息。 + +*运行meeda轻节点* + +启动meeda轻节点时需要设置sk参数。sk用于轻节点签署以太坊上的交易。轻节点启动时会查询其质押额，如果质押额不足，将会进行质押。还可以指定存储节点的ip地址，用于从存储节点访问数据相关信息。默认值为：http://183.240.197.189:38082。 + +meeda轻节点部署完成后，轻节点的rpc接口将绑定到8082端口。 + +部署到product链上： + +```bash +meeda light run --sk= --ip= +``` + +部署在dev链上： + +```bash +meeda light run --chain=dev --sk= --ip= +``` + +查询收益信息： + +```bash +meeda light profit +``` + +关闭meeda轻节点：为了正常停止轻节点，请在节点运行的终端中使用 `Control + C` 命令。 + +### 2.4.6 简化与dApp的交互（Simplify Interaction with dApps） + +**编译源码** + +```bash +git clone git@132.232.87.203:middleware/backend.git +cd backend +make all +``` + +**启动** + +```bash +./backend daemon run -e :8081 +``` + +### 2.4.7 智能合约地址（Smart Contract Address） + +在 MEMO 中，使用一系列智能合约来实现结算层，对于主网，我们列出了这些合约的地址。 + +**主网的智能合约** + +网络：MEMO 生产链。 + +合约： + +| Name | Address | +| --- | --- | +| authAddr | 0xCBd87cDE93FC0232aE05512e1c62a5Daff60758b | +| instanceAddr | 0x9fB373203AFa1D23fbC35a3E5651A4Ec93558a73 | +| proxyAddr | 0xF7899eE2C717dAC15E427786950a21350a1d2466 | +| control1Addr | 0x1AF33136Eb354363D5d95F445Bf63a5D35a0db58 | +| control2Addr | 0xFFD282f30070DFC2fC34A1e477f85F65C226Ce4E | +| control3Addr | 0xD8cD9849ad8dEC3Cbe8c3064026Db92faa6DE549 | +| tokenAddr | 0x42358a0764074B398762BeCbE5EEEceEeC38688D | +| filesysAddr | 0x9db4E0eF558865369a620C9B7953C965e0703D5f | +| groupAddr | 0xd1868E0f180089de485CB2B61a03851606bD0FF2 | +| issuanceAddr | 0xccc3F8E3BcdCCDB8eAE6816f4e21B228C09B52C0 | +| poolpAddr | 0xae48dce0964D704B66cC8430Db699237625079B7 | +| pledgeAddr | 0xb84FeD4f37BCfD3d540baC3141e19D9547277F40 | +| poolfAddr | 0xAe03503165ab2a7c0877B635b0d9e27f44BbfBdd | +| roleAddr | 0xB56D2081291a9506B12355346CfA1Fe2d276AD5f | +| getterAddr | 0xe1748d3AF86382c9e955Adb3501090b35EF8B1a8 | +| kmanageAddr | 0xb70a49976aA5b3936f46f195474e479150aE2033 | +| swapAddr | 0x51BA57383B488323Ac9FC28dE166AEeB427100ef | +| rewardAccessAddr | 0x4Cbdbd6E3a3034e51B33276CbAB6bF8AF97deF73 | +| rewardAddr | 0x2CC45e0D31244F3102a2521E3CBFefb580C4F070 | + +管理员地址： + +| Index | Address | +| --- | --- | +| 1 | 0xcdb5e0cb700e851a79e00347fff38d6b1b77dcb4 | +| 2 | 0x83811883303bcbe99db23d0e67c65b076b46188b | +| 3 | 0x36dbbdd363b5f201817262f966109880c672aa47 | +| 4 | 0x44e0b3ceb6ceef6382903b74bbb94cb07e6590f8 | +| 5 | 0xcd83055ed61401e6ba04b32a2a4839c9cac04e8f | +| 6 | 0xa7fe364e020839847b98844e52b6e43680898e75 | +| 7 | 0xece228752d719d858a231557f9ac88885dda7969 | +| 8 | 0x6b4034f6bbc65146bb6fa9556e6bb44f061f8421 | +| 9 | 0x94d42e9742c6ec74d048f381345d61d932a9c06c | +| 10 | 0xc55b576d1787ff13258ce15218ec76c8f49ecce7 | +# 三、Tokenomics（代币经济学） + +## 3.1 MEMO & Deposit（MEMO 与质押） + +### 总体设计 + +Memo 的设计分为三层： + +- 结算层：用于角色注册、群组管理以及费用结算。 +- 数据管理层：用于数据管理：订单聚合、挑战和修复调度。 +- 存储层：负责存储数据和响应数据请求。 + +三种角色：系统中有三种角色：用户、守护者和提供者。一个账户只能承担一种角色。 + +- 守护者：负责数据管理。 +- 提供者：负责数据存储。 +- 用户：数据提供者。 + +### 结算层 + +**结算层的功能** + +- 角色注册：每个账户进入此系统的门槛是在结算层注册成为系统账户。 +- 群组管理：群组作为整体管理单位，一个账户只能选择加入一个群组；守护者必须被批准才能加入群组，而提供者和用户可以自由加入；群组内的守护者共同管理该群组的存储数据信息（暂时没有退出机制）。 +- 质押池管理：每个账户可以将代币放入质押池，根据质押的代币数量分配利润。 +- 存储结算池：用户支付的费用将在结算池中被冻结，并根据实际存储时长、大小和价格进行支付。 + +**存储收入** + +- 用户支付：用户和提供者签署存储订单后，由守护者群组提交至结算层。在存储结算池中，订单费用将从用户的余额中扣除然后被冻结。 +- 提供者：提供者在连续响应挑战后，获得空间-时间费用凭证，然后根据凭证在结算池中获得收入。 +- 守护者：对于每个订单，守护者群组收取一定比例的费用，例如，4%；守护者群组的成员根据他们对群组的贡献分配这部分费用；费用以两种方式释放：1. 75% 在提供者获得收入时获得，线性释放；2. 剩余的 25% 在订单过期后获得。 +- 基金会：基金会收取 1% 的管理费。 + +**示例**：如果用户以 1 代币/（天\*GB）的费率存储 1GB 数据 100 天，用户需要为这个订单支付 105 个代币，其中 100 个代币给提供者，4 个代币给群组，1 个代币给基金会；在第 0 天，基金会可以获得 1 个代币，提供者和群组都不能获得任何东西；在第 10 天，提供者可以获得 10 个代币，群组可以获得 0.3 个代币；在第 90 天，提供者可以获得 90 个代币，群组可以获得 2.7 个代币；在第 100 天，提供者获得全部 100 个代币，群组获得 4 个代币。 + +**质押收入**：每个账户都可以投资质押池，质押池根据所有账户的质押份额分配利润。质押池的收入来自激励。随着存储规模的扩大，系统根据存储规模和价格等因素向质押池发放激励。 + +## 3.2 Distribution（代币分配） + +### 初始代币分配 + +$MEMO 的总供应量为 3亿枚，总供应量的分配如下（代币分配比例可以根据实际情况进行调整）： + +- 基金会账户：15%，用于技术和生态系统发展。 +- 投资者：10%。 +- 流动性账户：15%，用于空投和交易。 +- 激励账户：60%，用于支付质押池的激励。 + +### 从承诺池中释放激励 + +- 激励因子 A，最初设置为 1；当前总存储时间为 st，当前总存储容量为 s；如果 st/max(s, 100TB) > 1 年，解锁 A=1.2；如果 st/max(s, 1PB) > 1 年，解锁 A=1.5；如果 st/max(s, 10PB) > 1 年，解锁 A=2；鼓励大家增加存储以解锁更高比例，从而提高奖励上限。 +- 激励金额：目前需要支付的存储总金额为 m，平均存储时长为 T，如果没有分配奖励的时间为 t，则激励为 Amt/T。 + +起初，增加存储以解锁更高的激励比例，并获得更高的激励回报；当奖励较高时，即存储市场较大时，代币持有者将倾向于将他们的代币放入质押池以增加收入，从而减少市场流动性并提高代币价格；抑制新的存储需求。 + +### 冷启动 + +- 空投到用户账户以支付存储费用（直接打入结算池，有使用限制）。 +- 空投到守护者/提供者账户以进行质押。 + +--- + +# 四、Ecosystem（生态系统） + +## 4.1 MEFS + +### 引言 + +MEFS（MEMO是一个围绕区块链构建的大规模去中心化数据存储系统，具有高安全性和可靠性。它是一种新一代的区块链去中心化云存储协议，组织全球边缘存储节点为用户提供安全、可靠和高可用的存储服务。 + +MEFS（MEMO 文件系统）是 MEMO 的文件存储系统。 + +MEMO 是由 MEMO Labs 开发的新一代区块链去中心化云存储协议。我们的使命是为 Web3.0 构建可靠的基础设施。为了实现高可扩展性和可用性，MEMO 在数据分层、验证、容错和恢复机制方面进行了大量创新。MEMO 在区块链云存储方面取得了技术突破，采用了新的架构和多项创新。 + +MEMO 设计了三种用户角色：用户，即存储空间用户；提供者，即存储空间提供者；守护者，即协调管理人。这三个相互联系的角色由智能合约驱动，相互制约。 + +MEMO 可以分为三个基于功能的角色层：结算、验证和存储。结算层通过聚合订单信息并在链上处理结算，将每个订单的金额发送给存储节点的提供者。验证层在链下进行。守护者节点挑战提供者节点，验证证明的结果，并决定是否向提供者节点发放提款凭证。验证层的所有过程都将通过同一层的节点进行，并经过拜占庭容错共识。存储层由大量的分散的提供者节点组成，它们存储真实的用户数据，并定期向验证层提交存储证明。 + +**参考资料：** +- 什么是 MEMO？[Memoriae — 基于区块链的去中心化云存储的下一代](https://memolabs.medium.com/memoriae-next-generation-of-decentralized-cloud-storage-based-on-blockchain-9151ab8c1aaa) +- Roles：[构建自治存储系统：Memoriae 中的角色设计](https://memolabs.medium.com/build-an-autonomous-storage-system-role-design-in-memoriae-f724c405ddc)、[Memoriae 系统节点匹配](https://memolabs.medium.com/memoriae-system-node-matching-d246fca41009) +- 技术：[MEMO 去中心化云存储系统的多级容错机制设计](https://memolabs.medium.com/multilevel-fault-tolerant-mechanism-design-for-memo-decentralized-cloud-storage-system-f3c585eb401d)、[MEMO 原始数据恢复策略：风险感知故障识别 (RAFI)](https://medium.com/memolabs/the-risk-aware-failure-identification-rafi-strategy-of-memo-decentralized-cloud-storage-system-6c5990ec8cb3) + +### 注册认证令牌 + +用户点击 Memoriae 钱包（开发中）中的链接以获取测试令牌，系统将向用户发送 10 Memo 的测试令牌。当用户的测试余额不低于 10 Memo 时，他们将无法再次申请测试令牌。 + +发送电子邮件至 sup@memolabs.org 申请测试令牌。邮件主题：申请测试令牌；邮件内容：账户地址（例如 0x...），角色（提供者或守护者或用户）。 + +### 互动论坛 + +对去中心化数据存储系统感兴趣的人欢迎加入 Memo 社区并参与互动！GitHub：https://github.com/memoio/testnet/issues ；Twitter：https://twitter.com/Memo_Labs + +### 特点和优势 + +- **去中心化存储**：用户上传源文件后，Memo 系统可以将数据分发到多个存储节点，并对外提供统一标准化的接口。当目标用户发起下载请求时，最近的节点通过最近的节点下载片段并完整地提供给用户。网络中提供多个图像或副本，大大提高了访问速度和稳定性。 +- **全球共享**：多个 Memo 设备可以形成集群效应，实现全球数据共享、统一存储空间管理和云存储平台的自动负载均衡。文件可以跨区域和网络分布，支持整个网络的数据存储和高效使用，按需扩展以满足用户对高速扩展的需求。 +- **数据安全**：数据存储功能是 Memo 的基石，数据的安全性和可靠性是数据存储功能的基石。Memo 的数据隐私政策要求在写入边缘存储设备之前，源客户端的数据必须使用用户密钥进行加密。此外，访问控制机制确保数据可以由其所有者或其维护者和存储协作访问，而不会被其他用户或无关的维护者和存储者访问。 +- **系统可靠性**：Memo 确保可靠性的目标是防止用户设备、维护设备或边缘存储设备失败时数据丢失。可以使用复制、擦除编码等数据冗余技术来确保边缘存储设备上存储的数据的可靠性。 +- **原始数据恢复方法 - RAFI**：除了数据冗余机制外，数据修复方法也是决定数据可靠性的重要因素。Memo 的原始数据恢复方法 RAFI 用于进一步提高边缘存储设备中存储数据的可靠性。RAFI 技术可以优化边缘存储空间，并更多地保证数据的安全性和系统的稳定性。通过实时查询，可以快速发现高风险的数据丢失，有效地缩短数据修复的总时间并提高性能。 + +**与其他区块链存储项目相比，MEMO 有什么特别之处？** MEMO 是一个基于区块链的去中心化云存储系统。它与一些旨在生产区块的项目不同，这些项目的存储数据量直接与区块的计算能力相关；它也不同于伪去中心化的分布式存储项目，这些项目中的一个或几个节点通常承担"中心节点"的功能。 + +### Memo 系统的角色设计 + +在 Memo 分布式云存储系统中，每个用户可以根据自己需要注册一个角色。系统角色包括用户、守护者和提供者。如果是存储需求方，则注册为用户；如果是设备提供方，则注册为提供者；如果只提供信息管理服务，则注册为守护者。 + +这三个角色的基本职责如下： +1. 用户：是系统中的存储服务消费者，提出存储需求并上传数据 +2. 守护者：是系统中的管理协调员，负责信息中介和管理功能。 +3. 提供者：是系统中的存储设备提供者，为用户提供存储空间。 + +在这三个角色中，用户和提供者是存储服务的供需双方，用户也是系统中的最终用户。简而言之，用户使用 Memo 系统中的存储空间，守护者为用户找到合适的存储节点，存储节点提供者为用户提供数据存储。守护者相当于招聘平台上的猎头或房地产交易平台上的中介。 + +**角色概念** + +*1、用户*：由于系统中的最终用户是用户，因此需要为存储服务支付相应的存储费用，因此每个服务请求都由用户发起。当用户提出存储服务需求时，应包括以下要素：存储空间大小、存储时长；提供者和守护者的数量；以及所需的存储单位价格。因为只有在设置上述参数后，守护者才能检索和匹配相应的存储节点。同时，在去中心化云存储系统中，存储节点越多，数据越安全，但存储节点越多，支付的费用越高。因此，用户需要自己确定存储节点提供者和中间管理者守护者的数量，并需要在成本和数据安全之间找到平衡。用户不仅需要支付存储服务费用，当他们需要从提供者下载数据时，还需要支付下载费用，因为下载操作将给提供者带来流量和设备的消耗。由于用户是最终支付方，系统对这个角色没有设置особ限制，因为如果用户不支付，提供者和守护者将停止服务。 + +*2、守护者*：**基本功能** - 守护者是系统中重要的中介角色。它承担信息中介和管理功能，并从用户支付的存储费用中提取管理佣金。作为信息中介，其基本功能是匹配信息，即匹配需求方和供需方之间的信息。当用户提出存储需求时，守护者将根据用户的要求找到与自己连接的提供者，并匹配合适的存储节点。除了基本的信息匹配外，守护者的管理功能主要体现在参与挑战和触发支付上。守护者定期发起并参与对提供者的挑战。其目的是验证提供者是否完整存储数据，即验证提供者的真伪和诚信。根据挑战结果，我们可以了解每个提供者在这段时间内为用户有效存储了多少和多长时间的数据，这将作为用户后续支付的依据。此外，守护者另一个重要的功能是触发存储费用的支付。支付不是由支付方用户或支付方提供者触发的，而是由中间人守护者触发的。这主要是为了增加系统的公平性。由中间人守护者触发可以减少欺诈行为的概率。 + +**惩罚机制**：守护者作为中介，参与系统的管理。虽然它在一定程度上可以解决分布式存储系统存储供需的信任问题，但认为守护者本身可能缺乏诚信，例如不及时挑战存储的数据，不及时触发支付。为了触发支付，Memo 因此为角色设计了惩罚措施。惩罚机制的存在可以在一定程度上确保系统的良性运行和社区的健康发展。因此，系统规定，当账户注册为守护者时，必须质押费用。这个费用可以由账户退还，也可以在账户违反系统规定时扣除。如果账户质押的金额不足，或者没有质押存款金额，那么就没有诚信背书，账户的守护者角色无法建立。通常，当账户严重违反系统规定时，将对账户进行处罚。如果守护者无法按时进行存储数据的空间-时间挑战，同步空间-时间挑战的结果并报告空间-时间挑战的结果很长时间，那么系统将禁止该账户。一旦账户被禁止，它将永远不会再成为守护者。当守护者被禁用时，如果守护者质押的余额不为 0，则该余额可以如下处理：归还给账户；转移给部署角色合约的角色管理员；转移给违反系统规定的守护者。 + +*3、提供者*：**基本功能** - 提供者是系统中提供存储空间的一方。它为用户提供存储服务，并从用户那里获得支付的费用。提供者上线后，需要说明自己的存储情况，包括可用的存储空间、存储时长和所需的存储单价。提供者说明自己的情况后，守护者可以根据用户和提供者的情况匹配，然后将匹配的提供者信息发送给用户，以便用户、守护者和提供者形成一个存储服务。像守护者一样，提供者也有触发支付的功能，只不过守护者触发的是存储费用的支付，而提供者触发的是下载费用的支付。 + +**惩罚机制**：对于提供者，系统也设计了奖励和惩罚机制，因为提供者可能会有问题，比如数据损坏但不恢复，长期不响应用户下载数据请求或守护者挑战。这不仅会破坏用户的数据，还会严重影响用户体验。因此，对于提供者角色，在申请角色时也需要质押费用。一旦提供者违反系统规则，系统将触发相应的惩罚来扣除质押的金额。 + +**惩罚合约部署者：第三方合约管理员 Admin**：从系统设计的角度来看，每个角色都可以在 Memo 系统中获得收益。由于用户是最终消费者，惩罚措施主要是针对收集角色，即守护者和提供者，系统角色功能的实现和角色之间的互动是通过智能合约实现的，因此惩罚也是通过智能合约实现的。采用基于合约的惩罚机制的原因是：在低信誉环境中部署的去中心化系统，没有具体的组织决策，实施奖惩，而合约具有所有事先制定的条款和执行流程，并且是在计算机的绝对控制下执行的优势。借助智能合约的这些优势，可以事先在合约中规定提供者和守护者的惩罚机制。触发质押扣除功能的权力应该转移到一个无关的第三方，即角色合约部署者，这里称为合约管理员 Admin。Admin 部署惩罚合约，这也是 Memo 系统为了实现公平交易而设计的一种制衡机制。 + +### 每个角色的要求 + +**硬件要求**：守护者和提供者需要长时间在线。**系统要求**：确保 keystore 文件的安全。 + +- **用户**推荐配置：4 核心，8G 内存，20Mbps 带宽；外部网络 IP，端口 4001 可用；Docker 环境。 +- **守护者**推荐配置：4 核心处理器，8G 运行内存，200GB 存储空间，20Mbps 网络带宽；互联网 IP 地址，端口 4001 已开放；Docker 环境。 +- **提供者**推荐配置：4 核心，8G 内存，1TB 存储，20Mbps 带宽；外部网络 IP，端口 4001 可用；Docker 环境。 + +### 关于 RAFI + +RAFI 作为一种新的风险感知故障识别策略，它使用不同的时间阈值来识别不同数量失败块的条带故障，以期在更短的识别时间内提高整体数据的可靠性和可用性。[了解更多](https://www.usenix.org/conference/atc18/presentation/fang) + +## 4.2 Data Wallet（数据钱包） + +Data Wallet是一种包含管理用户身份以及数据资产的加密钱包，使用Data Wallet可以像管理FT/NFT一样管理数据资产。数据资产是针对用户个人数据（web2数据或者web3数据）资产化、代币化后的产物，并且针对数据资产额外添加了Reader角色，允许Reader角色访问个人数据。 + +当使用传统钱包时，用户Alice可以通过钱包获取账户下所有的数据，但是当用户Bob将用户Alice添加某个数据的Reader时，用户无法通过传统钱包获取到该数据。但是使用Data Wallet的话，可以通过钱包访问到这部分数据。 + +**Data Wallet是怎么运作的？** + +和传统钱包类似，Data Wallet并不会存储用户的个人数据。Data Wallet只提供和区块链以及存储系统交互的工具。具体而言，Data Wallet会保留一对或多对公私钥用于和区块链交互，同时Data Wallet会保留单个或者多个加密密钥用于和存储系统交互。 + +用户在第一次打开Data Wallet时会生成一对公私钥，同时生成一系列助记词。用户私钥会加密保存在Data Wallet中，并公开由公钥生成的地址以及用户ID。通过私钥用户可以转移用户持有的资产（FT/NFT/数据资产），可以将资产从一个地址转移到另一个地址。此外，Data Wallet会为不同的存储系统生成并保存不同的加密密钥，加密密钥用于加解密用户存放在存储系统中的个人数据。 + +## 4.3 Data Market（数据交易市场） + +### 概述 + +Data Market是一个基于区块链技术的去中心化数据交易市场，它通过利用以太坊智能合约来确保交易的安全性和透明度，同时采用MEFS存储来保障数据的持久性和可靠性。平台的核心竞争力在于其对DID（去中心化身份）的深度整合，使得用户能够更安全、便捷地管理自己的NFT资产。 + +### NFT + +非同质化代币（Non-Fungible Token，NFT）是一种加密货币，与传统加密货币如比特币等有所不同。比特币是等价的，每个比特币在使用过程中没有差异，如果一个比特币能购买一个苹果，那么其他任何一个比特币也能购买一个苹果。相比之下，NFT具有独特的价值，通常用于代表现实世界的资产，如精心创作的艺术品、音乐或电影等。NFT的价值取决于与之关联的资产，例如代表书籍《西游记》的NFT和代表画作《星空》的NFT拥有完全不同的价值。即使是十个代表书籍《西游记》的NFT，由于书籍的新旧、是否经手名人、书籍的批注等信息，它们的价值也可能各不相同。 + +### ETH合约的应用 + +在Data Market中，ETH智能合约扮演着核心角色。它们定义了平台上交易的规则和逻辑，包括但不限于资产的创建、交易和所有权转移。智能合约的自动化特性确保了交易的执行无需第三方干预，同时保障了交易的不可篡改性和透明性。 + +### MEFS存储的优势 + +MEFS（MEmo File System）是MEMO项目的一部分，它是一个基于区块链的分布式文件系统，以高可用性、易扩展和高性能著称。Data Market通过MEFS存储方案，实现了"IPFS+MEFS"的双重存储优势，为用户提供了去中心化的可靠存储和双重备份，确保了数据的安全性和持久性。 + +### DID与NFT资产管理 + +Data Market特别强调利用DID进行NFT资产管理。DID允许用户完全控制自己的数字身份，不需要通过中心化机构授权，这正符合Web3的去中心化理念。用户可以利用加密钱包作为数字身份标识，并通过NFT的真实性可验证，减少诈骗和虚假行为，使平台拥有真实可信的用户数据。 + +### 平台功能 + +Data Market提供了全面的NFT系统功能，包括资产创建、交易、展示、追踪和社区参与。平台支持创作者创建独特的NFT资产，并为其定义属性和特征。同时，它还提供了一个市场，让买家和卖家能够进行NFT交易，包括拍卖、一口价购买和市场交易等。 + +## 4.4 Computing Power Platform（算力平台） + +Computing Power Platform是一个为计算节点和用户提供交易市场的综合系统，Computing Power Platform要求任何计算节点在注册时提供SGX远程证明，确保计算节点能够提供TEE环境，从而保证用户个人数据在AI训练中不会泄露。此外，用户在创建订单并在计算节点中执行AI训练时，计算节点需要定期提交算力证明，确保计算节点的算力真实性。 + +### 角色设计 + +在Computing Power Platform中存在多种角色，其中包括用户，算力资源提供者，验证者。如果是计算资源需求者，则注册为用户；如果是设备提供者，则注册为算力资源提供者；若提供信息管理服务，则注册为验证者。 + +**用户**：用户是Computing Power Platform最终服务对象，绝大部分功能和机制都是为了更好地服务用户，并且确保用户在使用Computing Power Platform服务时的安全性。因此服务请求由用户发起并且需要用户支付一定的费用。用户需要根据算力资源提供者的算力大小，即CPU/GPU型号，支付一定的费用后与算力资源提供者签订订单。订单激活后，您可以开始在计算节点上部署应用程序并将您的个人数据通过安全信道传输到算力资源提供者的机器上，从而利用购买的计算资源进行计算或者AI训练。用户为订单支付的代币将根据为用户提供的实际服务时长进行结算。算力资源提供者需要每隔一段时间提交算力证明，只有提交正确的证明，算力资源提供者才会接收到部分订单金额。 + +**算力资源提供者**：算力资源提供者为Computing Power Platform中的用户提供实际算力设备，例如CPU/GPU。利用容器编排软件将现有的硬件资源（包括处理器、内存、存储、显卡等）进行组织，并启动网关服务对外提供各种API接口，实现身份认证、应用部署、应用访问以及算力验证功能。在部署本地基础设施并启动网关服务后，算力资源提供者还需要将自己的节点信息注册到区块链上并附带SGX远程证明，实现节点的公开以及可信执行环境的验证。并且为了预防算力资源提供者在后续过程中作恶，需要算力资源提供者在注册时质押一定的代币。在应用部署时，从部署请求中提供的YAML文件URL下载资源描述文件，节点再与容器编排软件交互，将资源描述文件中描述的应用部署到本地环境，从而完成算力服务的提供。 + +**验证者**：验证者主要参与Computing Power Platform的证明验证，包括TEE证明以及算力证明。验证者需要定期对算力资源提供者发起挑战，已验证算力资源提供者提供的算力真实性。此外，验证者还会验证算力资源提供者提交到链上的TEE证明。 + +### 算力证明 + +算力证明，即工作量证明是一种需要大量计算资源才能解决的加密难题，因此验证该加密难题的结果，即可验证CPU/GPU的算力。工作量证明依赖于哈希算法的不可逆性，这意味着只能从原始数据计算出相应的哈希值，而无法从哈希值逆向推导出原始数据。其次，哈希算法具有雪崩效应，即输入数据的微小变化会导致散列值的巨大差异。 + +这两种特性意味着，若要计算指定哈希值的原始数据，唯一的办法是不停地改变原始数据并执行哈希计算，并将哈希结果和指定哈希值对比。对于指定哈希值来说，每一次哈希都有极低的概率得到指定哈希值，因此往往需要大量哈希计算才能计算出与指定哈希值对应的原始数据，并且这些哈希计算相互之间完全不影响。并且哈希函数可以在CPU/GPU中并行计算，因此够真实反应CPU/GPU的真实算力水平。 + +### 可信执行环境 + +可信执行环境是中央处理器中隔离的执行环境，能够确保执行程序以及数据的完整性和机密性，因此能够在不泄露用户数据的前提下获得预期的结构。此外，可信执行环境还提供远程认证功能，远程认证功能允许TEE节点生成计算环境报告并提交上链，从而允许验证节点验证计算结果的正确性以及计算环境的私密性。 + +## 4.5 What's Meeda（Meeda 详解） + +### Meeda 简介 + +Meeda是由[Memolabs](https://memolabs.org/)推出的基于以太坊安全性的数据可用性解决方案，为以太坊Rollup提供可靠的数据可用性保障。 + +Meeda的命名来源于MEMO、Ethereum、data availability这些单词，并且与Memolabs推出的比特币数据可用性解决方案Mooda进行联动，前两个字母共同组成MEMO。 + +### DA问题 + +对于区块链来说，数据可用性（DA）是一件很重要的事情。众所周知，共识是组成区块链的重要一环，节点达成共识，从而共同维护当前链的状态。而节点要想达成共识，首先节点需要认可当前链的状态更改，要验证当前链的状态更改是否正确，就需要能够访问交易数据，执行交易获得交易结果，从而验证当前链的状态更改是否正确。所以保证交易数据能够被任意节点访问是区块链能够正常运行中非常重要的一环。 + +保证交易数据能够被任意节点访问就被称为数据可用性（DA，Data Availability）。任意节点可以访问到未被最终确认的区块中包含的交易数据，从而验证交易是否正确，以此防范恶意交易上链，维持区块链正确的"记账"记录，保障区块链的安全可靠性。（更详细描述参考 https://ethereum.org/en/developers/docs/data-availability/ ） + +在像以太坊这样的整体区块链中，DA通常作为单个系统设计的一部分，在区块空间有限而区块空间利用率较高时，Gas费会越来越高，单笔交易成本越来越高，用户体验会越差，Web3的发展也会受制。 + +以太坊最近几年也意识到了扩容问题，开始探索各种链下扩容解决方案，当前，Rollups已经成为流行的解决方案，但是在Web3生态繁荣、区块空间需求较高时，仍然面临Gas费过高问题。 + +**当前DA解决方案**：Layer2作为以太坊的扩容方案，已经能够安全可靠的对Layer1进行扩展，提升吞吐量并降低交易费开销。但其仍存在一个问题：无法降低数据的同步开销和存储开销。原始的交易数据仍然需要提交到L1链上，L1上的全节点仍需要同步这些交易数据。即使有一些别的方案，如ERC-4337来压缩部分交易数据，以及EIP-4844引入了`blob`交易类型，但效果仍旧有限。最直观的体现就是，这些交易数据存放在L1链上仍需要支付高昂的gas费用，尽管这些费用是字节费用而非执行费用。究其根本，还是因为Layer2将以太坊L1链当作自己的DA层。 + +### Meeda解决方案 + +**Meeda概览**：Meeda将blob数据放在链下存储，获取数据用的索引和保证数据可用性的承诺证明放在链上存储。在保证了数据可用性的同时，也降低了链上的同步开销和存储开销，最大程度扩展区块链。Meeda兼容任何Optimistic类型的Layer2链，为其提供可靠的数据可用性保障。Meeda依靠链上验证、持续性证明以及冗余机制保障数据的可用性。 + +在链下，Rollup将blob数据上传至Meeda，Meeda保障blob数据的可用性，任意节点都可以快速方便地读取blob数据。在链上，Meeda会定期往链上提交数据可用性证明。 + +**Meeda架构**：Meeda的架构中包含四个主要组成部分： + +1. **Operator**：接收blob数据，对blob数据进行冗余编码和分割，随后将其分散发送到Storage Nodes；生成blob数据的索引信息commitment，并上传至链上，以便用户获取数据；聚合Storage Nodes生成的数据可用性承诺证明，将聚合证明提交至链上，以便进行链上验证。 +2. **Storage Nodes**：存储blob数据的节点；根据链上周期生成的seed信息，持续性生成数据可用性承诺证明，并发送给Operator。 +3. **验证合约**：主要负责链上验证。根据VRF-Sampling（Verifiable Random Function）周期生成seed信息，用于后续的证明生成和证明验证；对持续提交的聚合证明进行验证；并且保存用于获取数据的索引信息commitment。 +4. **Light Node**：对链上验证发起挑战。 + +### 4.5.1 Description（数据流详情） + +Meeda的整个数据流程如下： + +1. Layer2将blob数据发送给Meeda的Operator节点，Operator节点对数据进行冗余编码和分割之后，将其分散存储至Storage Nodes； +2. Operator节点同时生成数据的索引信息commitment，之后将commitment返回给Layer2以及上传至链上的验证合约进行保存，用户可以根据commitment获取相应的blob数据； +3. 链上的验证合约将会周期性根据VRF-Sampling生成一个随机种子，用于数据可用性抽样； +4. Storage Nodes根据随机种子持续性生成数据可用性承诺证明，用以响应数据可用性抽样； +5. Operator将从Storage Nodes接收到的证明聚合成一个固定大小的证明，并将聚合证明提交至链上的验证合约； +6. 链上的验证合约假定证明正确，不验证证明，仅保存证明，用户可以从链上访问历史证明信息； +7. Light Node负责监督聚合证明的正确性，在线下验证聚合证明，一旦发现错误，即可向验证合约发起挑战，验证合约才会验证聚合证明的正确性。 + +Meeda依赖于以太坊的安全性，使用链上验证、持续性证明以及冗余机制来提供高安全性的数据可用性保障。 + +**链上验证**：Meeda采用链上验证的方式，提供了更安全的数据可用性保障。Meeda的链上验证包含两个主要组成部分，分别是数据可用性抽样以及欺诈证明。 + +*数据可用性抽样*：如果没有数据可用性抽样，那么Storage Nodes会针对每一份数据，都会生成一份数据可用性承诺证明，之后聚合。虽然这样也能保障数据可用性，但是会大大增加整体的计算量，进而提高Storage Nodes的部署成本。Meeda的验证合约会根据VRF-Sampling定期生成一个随机种子seed，由seed确定抽样的样本。可验证随机函数（VRF）是一种随机数生成器（RNG），具有不可预测性、公平性、随机性以及防篡改性，VRF的结果是等概率且无法被预测的，因此抽样具有随机性。Meeda的数据可用性抽样是一种自适应抽样方式。它对交易状态还未在结算层上最终确认的blob数据进行全量挑战，对另外的blob数据进行抽样挑战。这样既能完全保证交易状态未最终确认的blob数据的可用性，也能极大概率保证其他blob数据的可用性。Storage Nodes根据seed以及存储的blob数据生成样本的可用性承诺证明，然后将证明发送给Operator。Operator会将这些证明聚合成一个固定大小的证明，并提交至验证合约。无论blob数据量有多大，聚合证明都是固定大小，不会随着blob数据量的增大而提高链上验证的成本。这种抽样方式在提供高安全的数据可用性时，极大地降低了成本。 + +*欺诈证明*：如果将验证涉及的全部计算都放在链上进行，那么将会带来巨大的成本，因此，Meeda引入了欺诈证明（Fraud Proof），从而在提供高安全性的同时降低成本。Light Node一旦发现提交至链上的聚合证明存在问题，就可以向验证合约提出质疑，从而发起挑战，合约将会对证明进行验证。如果挑战成功，Light Node将会获得奖励。如果没有Light Node提出质疑，那么验证合约将默认聚合证明是正确的。这种方式在提供高安全性的同时极大地降低了Meeda的成本。 + +**持续性证明**：Storage Nodes会根据验证合约定期生成的随机种子seed持续性生成数据可用性的承诺证明，并且会由Operator聚合之后提交至链上的验证合约。用户可以随时查看当前和以往的承诺证明，并且保障了用户随时都可以访问blob数据。 + +**冗余机制**：Meeda在接收Layer2的blob数据后，会对其进行冗余编码，之后会将其分散存储至Storage Nodes。即使一部分Storage Nodes作恶，Meeda也能从其他Storage Nodes中恢复完整的blob数据。这种机制提供了更高安全的数据可用性保障。 + +### 4.5.2 Node Type（节点类型） + +节点类型有三种：Storage Node、Light Node、Operator。 + +- **Storage Node**：也就是存储blob数据的节点，同时持续性生成数据可用性的承诺证明。Storage Node的部署对所有用户开放。 +- **Light Node**：对链上验证发起挑战。Light Node的部署对所有用户开放。 +- **Operator**：对数据进行冗余编码和分割，聚合承诺证明。Operator目前暂时由项目方部署。 + +### 4.5.3 Resource（资源与联系方式） + +Meeda是Memolabs为Layer2 Rollup提供数据可用性而创建的项目。以下是我们的一些资源链接，欢迎与我们进行沟通交流。 + +**联系我们**：email：contact@memolabs.org；Memolabs 官网：https://memolabs.org/ + +**沟通交流**：twitter：https://twitter.com/MemoLabsOrg；discord：Memo Labs (https://discord.com/invite/YG4Ydv2E7X)；telegram：https://t.me/MemoLabsio；reddit：https://www.reddit.com/user/memolabs/ + +## 4.6 What is ERC-7829（数据资产 NFT 标准） + +> ERC-7829，全称"数据资产 NFT" + +### 什么是 ERC-7829？ + +**ERC-7829**，全称"数据资产 NFT"，是一项拟议的以太坊代币标准，它扩展了现有的 ERC-721 非同质化代币 (NFT) 标准。它旨在将数据资产表示为 NFT，从而实现区块链上数字数据的更结构化、更安全的管理。 + +**主要特点：** + +- **向后兼容**：ERC-7829 建立在 ERC-721 标准之上，并与其保持兼容，确保与现有 NFT 基础设施的互操作性。 +- **与模块化数据层集成**：该标准强调与模块化数据层 (DA) 集成的重要性，以确保数据资产的安全性和可访问性，尤其是在不可信环境中。 +- **增强数据表示**：通过将数据资产表示为 NFT，ERC-7829 能够更好地追踪、归属和传输数字数据，符合去中心化数据管理的原则。 + +ERC-7829 旨在提供一种标准化方法来处理以太坊区块链上的数据资产，从而在去中心化应用程序中促进安全高效的数据管理实践。 + +了解更多：https://eips.ethereum.org/EIPS/eip-7829 + +## 4.7 ERC7921 + +*该页面在 GitBook 上目前仅有标题，暂无正文内容。* +# 五、MEMO AIAgent + +## 5.1 Introduction（简介） + +MEMO 致力于构建一个可信、开放且可扩展的 Web3 原生基础设施，使身份（DID）、认证（Attestation）、数据可用性（DA）及支付能力能够作为通用服务层提供给各类应用。在 AI Agent 崛起的背景下，MEMO 正在推动下一阶段的发展：**将高可信度、可验证、可支付、可交互的区块链能力无缝嵌入 AI Agent，让 Agent 成为真正能够处理链上资产、访问链上数据、执行链上任务的自主体。** + +在这个背景下，MEMO AIAGENT 文档目录将介绍一整套让 Agent 在区块链上安全地执行交易、调用协议与完成支付的机制，包括： + +- x402：AI Agent 的链上支付能力规范 +- EIP-8004：Agent 与链上服务间的标准化调用协议 +- DID / Attestation / DA：Agent 的可信身份与可信执行基础设施 +- MEMO Storage: 为Agent提供隐私保护的数据存储中间件 + +这份 Introduction 文档是整个 AI Agent 文档体系的入口，将帮助你逐步理解 MEMO 如何构建一个 **可验证、可支付、可协作** 的 Agent 生态。 + +### Why AI Agent Needs MEMO? + +传统 AI Agent 虽然能执行逻辑，但缺乏： + +- **可信身份**（无法证明"我是谁"） +- **可信权限**（无法证明"我被允许执行哪些动作"） +- **可验证执行**（无法证明"我真的做了这个动作"） +- **原生支付能力**（无法在链上处理费用、跨链转账、任务支付） +- **可审核的结果证明**（无法提供可验证的执行证据） + +MEMO 的基础服务正好对应这些缺口： + +| Agent 能力需求 | MEMO 提供 | +| --- | --- | +| 身份 | DID（EIP-7007） | +| 权限与证明 | Attestation | +| 执行可信度 | TEE + DA | +| 支付 | x402 + Pay Facilitator | +| 调用链上服务 | EIP-8004 | +| 数据源 | DA / MEMO Storage | + +这样，AI Agent 不再只是"一个能聊天能执行任务的程序"，而是真正变成 **链上身份 + 链上支付能力 + 可验证执行 + 钱包原生能力 + 服务调用** 的自主体。 + +### MEMO Architecture for AI Agent + +上图展示了 MEMO 的分层架构。从底层到上层分别是： + +**Infrastructure 层**：TEE、MEMO Storage、LLM —— 为 Agent 的执行与数据提供底层算力与环境。 + +**Core Services 层**：由 MEMO 的核心模块组成： + +- **DID（Authentication）**：为 Agent 提供独立身份 +- **Attestation**：为 Agent 的权限、声明和行为提供证明 +- **DA（Data Availability）**：保证 Agent 与链上任务间的数据可用性 +- **Pay Facilitator（x402 & extensions）**：提供链上支付能力，如 gas 支付、跨链支付 +- **MEMO Storage（Privacy-Preserving Storage）**：面向 Agent 的隐私保护数据存储中间件，支持端到端加密、基于 Attestation 的访问控制、与 TEE 的远程证明集成，以及数据写入承诺与 DA 绑定。 + +**Access 层**：通过 **EIP-8004 标准协议**（有 Python / JavaScript SDK），为 Agent、应用、MCP Tools 提供统一的服务调用接口（包含 MEMO Storage、DID、Attestation、DA、x402 支付等模块）。 + +**Application 层**：最终由 Apps、Agents、MCP Tools、Launchpad 构成。 + +这张图展示了：**AI Agent 是建立在 MEMO 全套基础设施之上的可信执行体，能够通过 EIP-8004 接入 MEMO 的所有链上功能。** + +### Trustless Agent Protocol Layer + +上图进一步说明了 **Trustless Agents Protocol Layer** 的核心角色： + +- 该层作为 **AI Agent 与区块链服务之间的中间协议层** +- Agent 的每次链上交互（认证、证明、DA、支付）都通过该层进行 +- DID、Attestation、DA、x402 支付、MEMO Storage 等模块分别通过区块链/存储提供可验证能力与数据路径 +- Agent 则通过调用该 Layer 实现实际的链上操作，如： + - 创建与使用 DID + - 获取/提交 Attestation + - 发起任务支付（x402） + - 访问链上数据 + - 与用户、应用、MCP 工具交互 + +这样，MEMO 构建出的 Agent 不是"中心化 API + LLM 模型"的传统结构，而是：**一个在链上有身份、能证明行为、能支付费用、能执行智能任务的自主 Agent。** + +### x402: Enabling Payment for AI Agents + +x402（以及 extensions）是 AI Agent 在区块链上支付的基础。它解决： + +- Agent 如何自动为任务支付 gas +- Agent 如何收款 +- Agent 如何管理自己的链上余额 +- 多任务协作时，费用如何由代理人之间清算 +- 跨链费用如何处理 + +**x402 是 AI Agent 能够"自我执行任务"的关键基础。** + +你将在 /x402 目录中看到：x402 协议介绍、应用场景、Agent 支付案例、与 Pay Facilitator 的关系。 + +### MEMO Storage: Privacy-Preserving Data Middleware + +MEMO Storage 为 Agent 提供面向隐私与合规的存储能力，特点包括： + +- **端到端加密**：数据在 Agent 侧加密后入库，服务端仅处理密文；密钥可结合 DID/Attestation 与策略分发。 +- **访问控制与审计**：基于 Attestation/Capability 的权限授予与收回，支持细粒度访问与操作审计。 +- **与 TEE 集成**：支持远程证明的机密计算场景，密钥/数据在 TEE 中安全处理与封装。 +- **可用性与可验证性**：数据承诺与 DA 进行绑定，支持检索与完整性校验。 +- **经济结算**：通过 x402 实现按量/按次计费的读写与带宽结算，支持微支付。 +- **统一接口**：通过 EIP-8004 提供上传、检索、授权、撤销等 API，配套 Python/JS SDK。 + +典型应用场景： + +- 私有知识库与向量检索的密文语料管理 +- 多 Agent 协作工作流中的中间产物与日志留存 +- "支付后可取"的受保护数据分发（pay-to-access） + +### EIP-8004: The Access Layer for Agents + +EIP-8004 是 AI Agent 与链上基础设施间的统一接口规范，用于标准化： + +- Agent 如何调用 DID 注册/解析 +- Agent 如何提交/验证 Attestation +- Agent 如何访问 DA +- Agent 如何执行支付（配合 x402） +- Agent 如何访问 MEMO Storage 或 TEE + +EIP-8004 为整个 MEMO AIAGENT 构建标准化 SDK 和 Framework，使开发者可以通过统一 API 创建：AI Agents、MCP Tools、上层应用（Apps / Launchpad）。 + +## 5.2 x402（AI Agent 支付协议） + +### 什么是 x402？ + +[x402.org](https://x402.org/) 是一个开放的支付协议，将稳定币支付能力直接带入纯粹的 HTTP 交互之中。 + +它重新启用了 `HTTP 402 Payment Required` 状态码，让服务器可以无缝为 API 或数字内容收取费用。 + +客户端（人类用户或 AI 代理）无需注册账号、无需 API Key、也无需复杂鉴权流程，即可通过程序化方式完成支付并获取资源。 + +### 为什么是 x402？ + +传统支付通道并不是为 Web 的速度或机器对机器（M2M）交互场景设计的：它们缓慢、昂贵，并且依赖注册与密钥配置。 + +x402 将"支付"直接嵌入到 Web 原生的请求–响应流中，使得即时、全球化、按使用计费的支付模式可以低成本集成——同时适用于人类用户与自治智能体。 + +### 优势 + +- 基于 402 状态码的简单 HTTP 集成 +- 按请求/按使用量付费的定价模式 +- 使用稳定币进行微支付（例如：Solana 上的 USDC） +- 原生适配智能代理：AI Agent 可自动发现与完成支付 +- 零摩擦：无需账号、无需 API Key、无需会话管理 + +### 5.2.1 How x402 Works（x402 如何工作） + +本页面介绍 x402 中完整的支付流程：从初始请求到最终链上结算。 + +**概述**：x402 通过简单的 HTTP 请求-响应模式实现可编程支付。当客户端请求一个需要付费的资源时，服务器返回支付要求，客户端提交支付，服务器在验证/结算成功后返回资源内容。 + +**交互流程**： + +1. `Client` 向 `resource server` 发起一次普通的 HTTP 请求。 +2. `Resource server` 返回 `402 Payment Required` 状态码，并在响应体中附带一个 `Payment Required Response` JSON 对象（描述支付要求）。 +3. `Client` 从响应中 `accepts` 字段的多个 `paymentDetails` 里选择其一，并根据该 `paymentDetails.scheme` 构造对应的 `Payment Payload`。 +4. `Client` 再次向 `resource server` 发起请求，并在请求头中加入 `X-PAYMENT`，其值为序列化后的 `Payment Payload`。 +5. `Resource server` 验证该 `Payment Payload` 是否有效：要么本地直接校验，要么将 `Payment Payload` 与所用的 `Payment Details` POST 到 `facilitator server` 的 `/verify` 接口。 +6. `Facilitator server` 根据 `Payment Payload` 的 `scheme` 与 `networkId` 执行验证逻辑，并返回一个 `Verification Response`。 +7. 若 `Verification Response` 有效，`resource server` 执行实际资源加工或任务；若无效，继续返回 `402 Payment Required` 以及新的 `Payment Required Response`。 +8. `Resource server` 结算支付：要么直接与区块链交互，要么将 `Payment Payload` 与 `Payment Details` POST 到 `facilitator server` 的 `/settle` 接口，由其代理执行。 +9. `Facilitator server` 根据 `Payment Payload` 的 `scheme` 与 `networkId` 向区块链提交支付交易。 +10. `Facilitator server` 等待该支付在链上确认。 +11. 支付确认后，`Facilitator server` 返回 `Payment Execution Response` 给资源服务器。 +12. `Resource server` 返回 `200 OK`，响应体为客户端所请求的资源；同时若支付已成功执行，会在响应头加入 `X-PAYMENT-RESPONSE`，其值为 Base64 编码后的 `Settlement Response` JSON。 + +上述流程保证：客户端按要求支付；服务器（或协助者 Facilitator）负责验证与结算；资源交付时可携带支付执行的结果证明，方便后续审计或追踪。 + +### 5.2.2 HTTP 402 + +数十年来，HTTP 402 Payment Required 一直被保留"未来使用"。x402 激活了它，并尝试"赎回互联网最初的原罪"。 + +**什么是 HTTP 402？** + +[HTTP 402](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.2) 是一个标准但极少被实际应用的 HTTP 响应状态码，表示访问该资源需要支付费用。 + +在 x402 中，该状态码被正式启用，用于： + +- 告知客户端（买家或智能代理）该资源需要支付。 +- 传递支付的具体信息：金额、币种、目标地址等。 +- 提供完成支付所需的程序化（机器可处理）信息。 + +**为什么 x402 使用 HTTP 402**：HTTP 402 的核心价值在于：让访问 Web 资源的支付可以"无摩擦、原生 API 化"。这对以下场景尤其重要： + +- 机器对机器（M2M）支付（如 AI Agent）。 +- 按次 / 按量付费模式（API 调用、内容按次访问等）。 +- 无需账号注册、无需传统支付渠道的微支付。 + +使用 402 状态码使得 x402 协议保持与 Web 原生兼容，可轻松嵌入任意基于 HTTP 的服务中。 + +**总结**：HTTP 402 是 x402 协议的基础：服务可以在标准的 HTTP 响应中直接声明支付要求。它的作用包括：明确标识需要支付、传递支付所需的全部关键字段、无缝集成到已有的 HTTP 请求-响应工作流。 + +借助 HTTP 402，支付不再是"跳出协议之外的附加流程"，而成为开放 Web 中一个标准、可自动化的组成部分。 + +### 5.2.3 MEMO Facilitator + +本页面解释 x402 协议中 **协助者（Facilitator）** 的角色。 + +Facilitator 是一个可选但强烈推荐部署的服务组件，用于简化客户端（买方）与服务器（卖方）之间的支付验证与链上结算流程。 + +**什么是 Facilitator？** Facilitator 是一个服务，它会：验证客户端提交的支付负载（payment payload）；代表服务器在区块链上完成支付结算。 + +通过使用 Facilitator，服务器无需直接保持与区块链节点的连接，也无需自行实现支付验证逻辑。这样可以降低运维复杂度，并确保交易的实时、准确验证。 + +**Facilitator 的职责**： + +- **验证支付**：检查客户端的支付负载是否满足服务器声明的支付要求。 +- **结算支付**：将已验证的支付提交到区块链，并监控确认结果。 +- **返回结果**：将验证与结算的结果返回给服务器，由服务器决定是否履行客户端的请求。 + +Facilitator 不托管资金，也不充当资产保管人——它仅基于客户端签名的负载执行验证与链上交易提交。 + +**为什么要使用 Facilitator？** 使用 Facilitator 可以带来以下好处：降低运维复杂度（服务器无需直接与区块链节点交互）；协议行为统一（不同服务之间的验证与结算流程标准化）；加速集成（服务可以在几乎无需区块链专项开发的情况下快速接入支付能力）。 + +虽然也可以在本地自行实现验证与结算，但采用 Facilitator 能加速协议的标准化落地，并减少实现错误的风险。 + +## 5.3 ERC-8004（Trustless Agents） + +### 背景与动机 + +随着越来越多基于 AI 的"代理(Agent)"出现，社区普遍希望建立一个开放、跨组织、无需事前信任的 Agent 网络。已有协议如 Google A2A 和 MCP 解决了代理间通信问题，但缺少链上信任层。 + +EIP-8004 的出现就是为了解决这个"信任赤字"。 + +### EIP-8004 概述 + +EIP-8004（正式名称"Trustless Agents"）是一个针对以太坊/EVM 链的提案，于 2025-08-13 发布。它通过引入三个轻量级的链上注册表为每个 Agent 提供： + +- 唯一、可查、可转让(NFT 方式)的身份 +- 可公开、结构化、可组合的信誉 +- 可验证的任务执行、输出和证明 + +从而让不同组织的 Agents 能在无预设信任的条件下安全发现、选择、协作。 + +> "This protocol proposes to use blockchains to discover, choose, and interact with agents across organizational boundaries without pre-existing trust" + +### 三大注册表(Registries) + +**Identity Registry**：每个 Agent 注册时 mint 一个 ERC-721 token；tokenURI 指向"agent registration file"(agent-card.json)，包含描述、endpoint 列表和支持的信任模型。这种设计使 Agent 身份可发现、可转让、可管理。 + +**Reputation Registry**：当 Agent 完成任务时，客户端可提供反馈，包括 0-100 的分数、可选标签和 off-chain URI。Feedback 事件写入链上，所有人/合约可读取。支持链上简单聚合和链下复杂算法。 + +**Validation Registry**：对于高价值/高风险的任务，Agent 可提交 validationRequest，请求验证器进行独立验证(如重执行、TEE attestation、zkML 验证等)。验证器调用 validationResponse()回应，系统保存为链上状态。 + +### Agent 注册与元数据(agent-card.json) + +典型结构包含：描述信息(name/description/image)；支持的通信框架(endpoints: A2A, MCP, DID 等)；支持的信任机制(reputation/crypto-economic/tee-attestation)。 + +这种方式允许不同 Agent 根据任务风险级别灵活选择信任机制。 + +### 任务执行、评价、验证流程 + +典型调用流程包括： + +1. Agent 注册(NFT + agent-card.json) +2. 用户/另一 Agent 发现 Agent +3. 发起任务调用 +4. Agent 执行任务 +5. 提交反馈到 reputation registry +6. 如需高验证，发起 validation request +7. 上层应用根据链上信息决定是否信任该 Agent + +### 与传统 Agent 协议的关系 + +MCP 负责公开和调用 Agents 的能力；A2A 处理代理间通信。但两者都不包含信任建立机制。 + +EIP-8004 作为补充，为 Agent 通信加上可公开、去中心化、标准化、可验证的信任基础。 + +### 风险/挑战/注意事项 + +- 声誉系统易被 Sybil 攻击、刷分等。feedbackAuth 预授权机制可减少恶意差评，但需社区构建更复杂防护 +- 验证机制的激励和规范尚未统一 +- 链上数据开销 vs. 链下复杂性之间需要平衡 +- 协议仍处于草案/社区审查阶段，未来标准可能调整 + +### 展望与落地方式 + +对于 MemoLabs + AIAgent 生态： + +- 部署 EIP-8004 注册表，让 Agent 在链上注册身份并发布能力列表 +- 构建 Agent Marketplace/Explorer，基于信誉和验证提供优选机制 +- 整合支付、信任和基础设施构建真正的"Agent 经济" +- 长期构建声誉聚合器、验证服务、保险和合规审计 + +### 总结 + +EIP-8004 是面向未来 Agent 经济的基础信任协议，定义了 Agent 的身份、信誉与验证的标准，使自治 Agent 能在无预设信任的条件下互相发现、信任与协作。 + +## 5.4 Attestation Server（AS，认证服务） + +### 概述 + +在当今世界中充斥着大量的虚假信息，无论是链上的信息还是链下的信息，我们难以从海量的信息中甄别出真实的信息。我们急需一种通用的方式来验证信息的真实性。 + +认证服务应运而生，AS是一种基于分布式账本或其他去中心化技术的数据认证系统，能够保证数据的真实性。AS允许任何实体对任何事物进行认证，从而提供对该事物的真实性保障。 + +### 为什么需要AS + +在如今信息爆炸的世界中，核实事实、证明信息的真实性和可信度至关重要。在现实世界中，人们无时无刻不在进行各种证明。公证员证明你签署了文件，医生证明你的健康状况，大学证明你的毕业证书，你证明你在社交媒体上发布的帖子和点赞，银行证明你符合贷款资格，甚至你的朋友也会证明他们喜欢你或信任你。这种互动不胜枚举。 + +然而在去中心化世界中，传统中心化机构的信任背书将不再有效，我们无法在去中心化世界中去相信一个唯一的实体。 + +AS允许任何人都能对任何事物进行链上或链下认证。您只需注册一个关于任何主题的模式（或使用现有模式），然后引用该模式进行认证即可。 + +### AS的优势 + +- **无需许可**：任何人都可以创建和验证证明，无需依赖特定中心化机构 +- **不可篡改**：链上存储的证明具有区块链的不可篡改特性 +- **可撤销**：支持证明的撤销机制，保持系统的灵活性 +- **成本效益**：链下存储选项降低gas成本，同时保持链上验证能力 + +### 应用场景 + +- **防女巫攻击**：在Web3生态中，通过证明验证用户不是机器人，确保代币空投和激励分配不被羊毛党主导。 +- **可信用户生成内容（UGC）**：验证内容真实性，如在线评论平台、问答社区等，在大模型时代确保数据可信度。 +- **身份与声誉系统**：构建去中心化身份和声誉图谱，不同平台的声誉数据可以聚合形成个人整体声誉。 +- **其他应用**：投票系统、真实性验证、市场合规、数字公证等。 + +### 5.4.1 How AS Work（AS 如何工作） + +AS主要基于以下两个主要合约来实现链上以及链下的证明，这两个合约分别负责模式的注册以及证明的创建： + +| 合约 | 功能 | 主要链上方法 | +| --- | --- | --- | +| SchemeRegistry | 注册一个证明模式，该模式描述了证明包含哪些结构化数据 | register() | +| AS | 创建一个证明，创建时需要指定模式，并包含相应的数据 | attest();attestByDelegation(); | + +**SchemeRegistry**：模式是您证明的模板，它规定了您要生成证明的格式和结构。您在生成证明之前，可以先查询是否存在有类似的模式能够满足您的需求，如果没有，您可以依据您的需求注册模式。如果您想发起投票，您可能需要"eventName"、"location"、"startTime"和"endTime"等字段。 + +以下是注册模式的一般流程： + +1. 查看是否有类似的模式可供使用； +2. 定义您的模式的结构； +3. 使用register方法，注册您的模式； +4. 注册成功后，合约会返回给您您的模式的唯一ID； +5. 现在，您可以使用您的模式创建证明了。 + +**AS**：确定好模式后，即可创建证明： + +1. 按照模式要求的数据结构构建证明； +2. 对证明中的结构化数据进行数字签名，从而创建链上和链下证明； +3. 将证明以及模式的唯一ID传入AS合约； +4. AS根据模式验证结构化数据并存储证明； +5. 该证明现已记录在区块链上，任何人都可以验证该证明！ + +## 5.5 MEFS MCP Server + +MEMO MCP Server为AI代理提供标准的存储接口，允许AI代理将生成的内容保存到MEFS并提供数据检索功能。为AI代理提供去中心化存储能力。 + +### 用例 + +- 数据加密存储：将AI生成的内容存储到MEFS。 +- 用户上下文检索：将用户的行为和偏好数据存储到MEFS，并在后续请求中，快速检索相关的用户数据并提供给AI代理。 +- 数据无缝分享：AI代理之间能够通过内容标识符 (CID) 实现了无需信任的数据分享。 + +### 免费额度 + +立即开始使用mefs-storage，即可免费享受10GB的存储空间。 + +### 快速安装指南 + +您可以按照以下步骤安装MCP服务器，在使用MEFS MECP server前，请确保您已创建了EVM私钥。 + +**前置条件**：在使用MEFS MECP server前，请确保您已创建了EVM私钥。您可以使用[MetaMask](https://metamask.io/)，[Okx Wallet](https://web3.okx.com/)等EVM钱包创建钱包，并获取您的私钥。 + +**配置 MCP 服务器（需要指定私钥）**：您可以在您的客户端中，使用以下配置启动MCP服务器（标准配置，适用于大多数客户端）： + +```json +{ + "mcpServers": { + "mefs-storage-server": { + "command": "npx", + "args": ["mefs-mcp-server"], + "env": { + "MCP_TRANSPORT_MODE": "stdio", + "MEFS_PRIVATE_KEY": "" + }, + "shell": true, + "cwd": "./" + } + } +} +``` + +将YOUR-PRIVATE-KEY替换为您的EVM私钥。 + +**SSE模式**：MEFS-MCP-SERVER支持SSE模式，您可以通过以下步骤启动SSE模式，并配置到您的个人AI代理中： + +克隆项目： + +```bash +git clone https://github.com/memoio/mefs-mcp-server.git && cd mefs-mcp-server +``` + +安装依赖： + +```bash +pnpm install +``` + +编译： + +```bash +pnpm run build +``` + +以SSE模式启动： + +```bash +pnpm run start:sse +``` + +您可以在项目的`.env`中配置`MEFS_PRIVATE_KEY`参数，或者使用`export`将`MEFS_PRIVATE_KEY`参数配置到环境变量中，或者使用以下命令启动，从而制定您的个人EVM私钥： + +```bash +MEFS_PRIVATE_KEY= pnpm run start:sse +``` + +配置MCP服务 (SSE mode)： + +```json +{ + "mcpServers": { + "mefs-storage-server": { + "url": "http://localhost:3001/sse" + } + } +} +``` + +### 使用MCP工具 + +MEFS MCP Server提供以下工具与去中心化存储网络MEFS交互： + +**上传**：上传文件到MEFS： + +```js +// Example usage in an AI application +const result = await uploadFile({ + file: base64EncodedContent, + name: "document.pdf", +}); +``` + +参数：`file`（Base64编码的文件内容）；`name`（带扩展名的文件名）。 + +**检索**：从MEFS网络检索文件： + +```javascript +// Example retrieval by CID +const document = await retrieveFile({ cid: "bafybei...gq5a/document.pdf" }); +``` + +参数：`cid`（文件的唯一标识符）。 + +## 5.6 Elizaos Plugin + +elizaos-plugin-mefs是一款专为elizaos代理提供去中心化存储功能的插件。该插件允许代理和去中心化存储网络——MEFS进行交互，提供文件上传和检索的功能。 + +### 安装 + +通过bun进行安装： + +```bash +bun install @elizaos/plugin-mefs +``` + +通过elizaos cli进行安装： + +```bash +elizaos plugins add @elizaos/plugin-mefs +``` + +### 配置 + +将插件添加到elizaos代理角色中： + +```js +// agent/src/character.ts +export const character: Character = { + name: 'Eliza', + plugins: [ + '@elizaos/plugin-mefs', + ], + ... +}; +``` + +设置环境变量，将下面的环境变量添加到.env文件中： + +``` +MEFS_PRIVATE_KEY= +``` + +将YOUR-PRIVATE-KEY替换为您的EVM私钥。您可以使用MetaMask、Okx Wallet等EVM钱包创建钱包，并获取您的私钥。 + +### Build And Run + +从项目的根目录构建并启动项目： + +```bash +elizaos start +``` + +您现在可以在浏览器中打开 http://localhost:3000，从而访问专属于您的AI代理。 + +### Actions + +**STORAGE_UPLOAD**：当用户想要将文件或者AI代理生成的回答上传到Storacha分布式存储网络时，请使用此操作。 + +别名：`UPLOAD`、`STORE`、`SAVE`、`PUT`、`PIN` + +**STORAGE_RETRIEVE**：当用户要求您根据 CID 从 Storacha 网络检索文件时，请使用此操作。 + +别名：`RETRIEVE`、`RETRIEVE_FILE`、`RETRIEVE_FILE_FROM_STORAGE`、`RETRIEVE_FILE_FROM_IPFS`、`GET`、`GET_FILE`、`GET_FILE_FROM_STORAGE`、`GET_FILE_FROM_IPFS`、`GET_FILE_FROM_CID`、`LOAD`、`LOAD_FILE`、`LOAD_FILE_FROM_STORAGE`、`LOAD_FILE_FROM_IPFS`、`LOAD_FILE_FROM_CID`、`READ`、`READ_FILE`、`READ_FILE_FROM_STORAGE`、`READ_FILE_FROM_IPFS`、`READ_FILE_FROM_CID` + +## 5.7 MEMO DID（Agent DID 规范） + +### 1.1 DID格式 + +MEMO DID的组成如下： + +``` +did:memo: +``` + +一个DID例子如下： + +``` +did:memo:ce5ac89f84530a1cf2cdee5a0643045a8b0a4995b1c765ba289d7859cfb1193e +``` + +其中`` = `hex(hash(address, nonce))`。`
`是以太坊地址，``等于`
`发起的交易nonce。 + +### 1.2 DID URL格式 + +MEMO DID URL组成如下： + +``` +did:memo: path [ ? ] [ # ] +``` + +例子： + +``` +did:memo:ce5ac89f84530a1cf2cdee5a0643045a8b0a4995b1c765ba289d7859cfb1193e#masterKey +did:memo:ce5ac89f84530a1cf2cdee5a0643045a8b0a4995b1c765ba289d7859cfb1193e#key-1 +``` + +支持以下path：暂无。支持以下query：暂无。支持以下fragment：`#masterKey`（指定主公钥）；`#key-`（指定其他的公钥）。 + +### 1.3 DID文档核心属性 + +**DID文档** + +| 属性名 | 是否必要 | 表示方法 | 用处 | +| --- | --- | --- | --- | +| id | 是 | 一个符合DID格式构成规则的字符串 | 用户ID | +| verificationMethod | 是 | 一组符合验证方法构成规则的验证方法 | 一组用于验证的公钥集合 | +| authentication | 否 | 一组符合DID URL格式构成规则的字符串 | 以该DID的名义认证登录 | +| assertionMethod | 否 | 一组符合DID URL格式构成规则的字符串 | 以该DID的名义发布可验证声明 | +| capabilityDelegation | 否 | 一组符合DID URL格式构成规则的字符串 | 委托他人管理该DID属下的文件 | +| recovery | 否 | 一组符合DID URL格式构成规则的字符串 | 用于密钥遗失后恢复密钥 | + +**验证方法** + +| 属性名 | 是否必要 | 表示方法 | 用处 | +| --- | --- | --- | --- | +| id | 是 | 一组符合DID URL格式构成规则的字符串 | 验证方法标识符 | +| controller | 是 | 一个符合DID格式构成规则的字符串 | 验证方法的所有者 | +| type | 是 | 一个字符串 | 验证方法类型 | +| publicKeyHex | 是 | 一个符合16进制编码的字符串 | 16进制表示的公钥信息 | + +**1.3.1 id属性**：在DID文档中，id表示与DID文档对应的DID标识符，必须给出且必须在DID文档的最顶层，且必须满足DID格式所描述的构成规则。 + +```json +{ + "@context": "https://www.w3.org/ns/did/v1", + "id": "did:memo:ce5ac89f84530a1cf2cdee5a0643045a8b0a4995b1c765ba289d7859cfb1193e" +} +``` + +**1.3.3 verificationMethod属性**：描述了一组验证证明的方式，通常使用公钥表示。通过公钥可以验证签名是否由对应的私钥签署，从而确定签名者的身份或权限。verificationMethod是必须的且至少包含主验证方法masterkey，需要包含以下属性： + +- **id**：必须是一个字符串且满足DID URL格式描述的构成规则。 +- **type**：必须是一个字符串，对应唯一的hash函数以及签名函数，从而描述了如何使用verificationMehtod中公钥验证签名。 +- **controller**：必须是一个字符串且满足DID格式描述的构成规则。controller表示被授予拥有更新verificationMethod属性中type属性以及publicKeyHex属性的权利，而DID的masterKey则无权修改。 +- **publicKeyHex**：必须是一个符合16进制编码的字符串，表示验证方案的压缩公钥。 + +```json +{ + "@context": "https://www.w3.org/ns/did/v1", + "id": "did:memo:ce5ac89f84530a1cf2cdee5a0643045a8b0a4995b1c765ba289d7859cfb1193e", + "verificationMethod": [ + { + "id": "did:memo:ce5ac89f84530a1cf2cdee5a0643045a8b0a4995b1c765ba289d7859cfb1193e#masterKey", + "type": "EcdsaSecp256k1VerificationKey2019", + "controller": "did:memo:0000000000000000000000000000000000000000000000000000000000000", + "publicKeyHex": "0x031c9cc1c36d53ff1feae79bbd32854a05b3cb4bbf4032383ed1eac79af9a918e7" + }, + { + "id": "did:memo:ce5ac89f84530a1cf2cdee5a0643045a8b0a4995b1c765ba289d7859cfb1193e#key-1", + "type": "EcdsaSecp256k1VerificationKey2019", + "controller": "did:memo:b69f63fe2f84d782b134624020802fa49c70f6fad8009c0be1da25229c2be99c", + "publicKeyHex": "0x02948b109c8298057c1d798d9a14ed30f33689d8397e2e60f89ef408b08d7f48a1" + } + ] +} +``` + +特殊验证方法masterKey：在每个DID文档的verificationMethod属性中，必然存在一个特殊的验证方法，其id为`{did}#masterKey`。该验证方法除了能够在线下验证签名者的身份外，也是线上合约验证签名者是否具有修改DID文档权限的方法，其他验证方法不具备该功能。masterKey所对应的验证方法中，controller的memo-specific-id以全零表示，这意味着masterKey不受任何具体的DID实体控制，即masterKey是无法修改的。 + +验证方法的controller：由于密钥无法控制自身，并且无法从DID文档中推断出验证方法的控制器，因此需要在验证方法中明确表达密钥控制器的身份。验证方法的controller仅拥有对单个验证方法中type和publicKeyHex属性进行修改的权限。通常情况下，验证方法controller均为DID实体本身，但可能这两者均不相同。 + +**1.3.4 authentication属性**：描述了网关或者服务商如何对DID实体的身份进行线下身份认证，通常用于用户登录网关或者执行任何类型的质询-响应协议等。是可选的；如果存在，则必须是一组字符串且满足DID URL格式构成规则。 + +**1.3.5 assertionMethod属性**：通常用于发布DID主体的声明，例如与可验证凭证结合，发布有关DID主体身份信息的声明（待定）。是可选的；如果存在，则必须是一组字符串且满足DID URL格式构成规则。 + +**1.3.6 capabilityDelegation属性**：用于授权文件管理。例如当用户登录网关后，需要先授予网关对该用户所属文件的访问和管理权限，才能访问网关的相应服务。为了授予网关管理文件的权限，用户需要将网关的特定验证方法（网关指定）添加到capabilityDelegation属性中。网关访问文件时，添加数字签名消息，并由验证者提取验证方法中的公钥验证数字签名。如果验证成功，则调用中有权访问受保护的资源。是可选的；如果存在，则必须是一组字符串且满足DID URL格式构成规则。 + +**1.3.7 recovery属性**：用于私钥丢失后恢复密钥（待定）。是可选的；如果存在，则必须是一组字符串且满足DID URL格式构成规则。 + +### 1.4 DID功能设计 + +**1.4.1 创建DID**：创建DID的接口如下： + +```go +Registe(did, publicKey) +``` + +在创建DID之前，需要生成did以及publicKey，其流程如下： + +- 生成一对公私钥，并生成地址； +- 获取链上随机数或者合约中随机数nonce； +- 根据nonce和地址计算hash并转换成16进制字符串，作为memo-specific-id； +- 在memo-specific-id前添加did:memo生成最终的did； + +调用该接口后，会将最终did以及公钥信息添加到交易消息中，同时使用私钥对交易进行签名。合约根据交易中信息，以及默认信息，如：验证方法id，type以及controller，生成并保存初始DID文档。 + +**1.4.2 查询DID** + +（1）解析DID：即通过DID解析DID文档，其接口如下： + +```go +Resolve(did) +``` + +在MEMO DID的合约中，所有的verificationMethod会依次序添加到verificationMethod数组中，因此解析verificationMethod中所有元素，只需遍历verificationMethod数组即可。其他的属性如：authentication，assertionMehod，capabilityDelegation以及recovery，则会在每次添加操作执行完成后，发出对应的事件，同时合约提供相应的查询接口，用以查询上述属性是否有效。因此，可以通过遍历相应的事件，同时调用查询接口，即可解析MEMO DID所有属性。至于@context属性，则会在上述解析完成后，默认添加。 + +（2）反引用解析DID URL：即通过DID URL解析得到验证方法，其接口如下： + +```go +Dereference(didUrl) +``` + +在MEMO DID中，DID URL即表示verificationMethod的ID，可解析为DID以及fragment两部分。因此，可通过DID定位到对应的verificationMthod数组，同时可以通过fragment定位到最终verificationMthod所在的位置。 + +**1.4.3 更新DID**：对于DID文档的修改，存在如下接口（均需相应权限方签名调用）： + +- 添加验证方法 `addVerificationMethod(did, type, controller, publicKeyHex)`，该接口仅masterKey可以调用； +- 修改验证方法 `updateVerificationMethod(methodID, type, publicKeyHex)`，该接口仅验证方法中controller可以调用； +- 撤销验证方法 `deactivateVerificationMethod(methodID)`，该接口仅masterKey可以调用； +- 添加认证方式 `addAuthentication(did, methodID)`，该接口仅masterKey可以调用； +- 撤销认证方式 `deactivateAuthentication(did, methodID)`，该接口仅masterKey可以调用； +- 添加用户声明验证方式 `addAssertionMethod(did, methodID)`，该接口仅masterKey可以调用； +- 撤销用户声明验证方式 `deactivateAssertionMethod(did, methodID)`，该接口仅masterKey可以调用； +- 添加文件代理方 `addCapabilityDelegation(did, methodID, expiration)`，该接口仅masterKey可以调用； +- 撤销文件代理方 `deactivateCapabilityDelegation(did, methodID)`，该接口仅masterKey可以调用； +- 添加密钥恢复 `addrecovery(did, methodID)`，该接口仅masterKey可以调用； +- 撤销密钥恢复 `deactivaterecovery(did, methodID)`，该接口仅masterKey可以调用； + +以`addVerificationMethod`为例：用户选择did以及controller（默认和did相同，但是可能存在单个用户拥有多个did，设定主did控制其他did和其验证方法）；用户生成一对公私钥，根据生成算法指定type；使用masterKey的私钥签名，并访问合约接口`addVerificationMethod(did, type, controller, publicKeyHex)`——合约验证签名是否由did masterKey所签，合约根据递增的number和did生成methodID，合约根据methodID、type、controller、publicKeyHex生成验证方法，并将验证方法添加到did文档的verificationMethod属性中。 + +`modifyVerifycationMethod`：用户选择methodID，解析出did以及methodIndex；用户生成一对公私钥并根据生成算法确定type；用户利用验证方法controller包含的masterKey对应的私钥签名，并访问合约接口——合约验证签名是否由methodID中controller所签，合约修改验证方法中type以及publicKeyHex属性。 + +`deactivateVerificationMethod`：用户选择methodID，解析出did以及methodIndex；用户使用did masterKey签名消息，访问合约接口——合约验证签名是否由did masterKey所签，合约删除对应的验证方法。 + +`addCapabilityDelegation`：用户选择did、methodID，并设置过期时间；用户使用masterKey签名消息，并访问合约接口——合约验证签名是否由did masterKey所签，合约添加methodID到文档的capabilityDelegation属性中，同时设置到期时间（到期时间对于展示给用户的DID文档来说是透明的，只有读取文档时合约会判断，但不会展示出来）。 + +一个完整DID文档示例（包含verificationMethod、authentication、assertionMethod、capabilityDelegation、recovery等全部属性）： + +```json +{ + "@context": "https://www.w3.org/ns/did/v1", + "id": "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96", + "verifycationMethod": [ + { + "id": "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96#masterKey", + "controller": "did:memo:0000000000000000000000000000000000000000000000000000000000000000", + "type": "EcdsaSecp256k1VerificationKey2019", + "publicKeyHex": "0x03d21e6c4843fa3f5d019e551131106e2075925b01da2a83dc177879a512eb608f" + }, + { + "id": "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96#key-1", + "controller": "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96", + "type": "EcdsaSecp256k1VerificationKey2019", + "publicKeyHex": "0x02d78b20654eb7a5d58d83b25d090a338eff18f0b5f919777c9d894c2e161b4b52" + } + ], + "authentication": [ + "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96#masterKey" + ], + "assertionMethod": [ + "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96#masterKey" + ], + "capabilityDelegation": [ + "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96#key-1" + ], + "recovery": [ + "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96#masterKey" + ] +} +``` +## 5.8 Detailed Description of Meeda（Meeda 详细技术说明） + +本文从开发者的角度详细讲解Meeda的整体交互流程，供开发者探讨交流。 + +### 上传文件 + +Rollup上传交易数据，Meeda会根据交易数据生成KZG多项式承诺`Commitment`，该值不仅可以唯一识别区块交易数据，也用于后续验证数据可用性证明的正确性。承诺值占用96字节，在合约中用`bytes32[4]`格式表示。之后Meeda会将交易数据的承诺值和元数据信息上传至以太坊等区块链进行持久化保存，从而保证获取数据的索引公开可访问。交易数据会被分割成多个切片，通过纠删码或多备份技术进行数据冗余，使得节点作恶成本大大增加。 + +### 下载文件 + +任意节点根据交易数据的承诺值可以轻松访问交易数据，在Meeda的数据可用性保障性下，轻节点将无需下载所有数据即可验证数据的可用性。 + +### 生成验证信息 + +根据kzg多项式承诺方案以及去中心化特性，将由合约定期生成一个伪随机数`rnd`，用来对存储节点发起挑战，`rnd`将会确定抽样的样本。存储节点针对被抽样的文件生成数据可用性证明。 + +Meeda的验证合约将保证该伪随机数无法被预测，并且只会在特定的短时期内生成，从而避免存储节点利用时间漏洞造假从而躲避惩罚。存储节点需要在确定的短时期内提交证明，超过了有效时期还未提交证明，则视为挑战失败，从而受到惩罚，并且还会触发数据修复。根据伪随机数，确定抽样的待挑战文件，保证挑选的文件具有随机性、不可预测性。 + +Meeda的抽样验证是一种自适应验证方式。它对新区块（例如最近 10 个 epoch 中的区块）进行全量挑战，并对旧区块进行抽样挑战。DA需要百分百保证交易数据是可获得的，因此，对于未最终确认的交易数据，Meeda会进行全量挑战，以百分百保证数据的可用性。对于较旧的数据，Meeda使用抽样挑战。 + +我们假设数据故障率为1/1000，也就是说1000个文件中只有1个是故障的（对于存储来说，这种级别的作恶是没有利润的，假设100GB的数据，邪恶节点只存储99.9GB的数据，这样对于他来说，风险是大于收益的，所以1/1000的故障率几乎是最低的故障率），那么挑战m次始终找不到错误数据的概率为(1-1/1000)^m，则发现故障数据的概率为1-(1-1/1000)^m。我们假设故障发现率为99.99%，也就是说可以99.99%的确定性发现故障，那么可以得到m约等于9205.7，我们假设每次抽样挑战1万个数据块，这样就能大于99.99%的概率发现故障数据。这种自适应的抽样检查，使得我们能够100%保证最近提交交易的数据可用性，大于99.99%的概率保证历史交易的数据可用性。 + +### 生成证明并提交 + +存储节点在链下生成待验证文件的数据持有证明，聚合这些证明，将聚合证明提交到链上。Meeda的验证合约假设证明是正确的，在证明被提交至验证合约时，合约不会立刻进行验证，当轻节点发起挑战时，验证合约才会对证明进行验证，从而减小验证开销、降低数据可用性的成本。 + +### 多轮交互式乐观验证 + +存储节点提交证明后，为了减少证明的代价，采用了多轮交互式的乐观验证方式。轻节点在链下对聚合承诺值和聚合证明值进行验证，如果发现错误，则可以针对该证明进行挑战。 + +如果是针对聚合承诺值的挑战，Meeda将采取多轮交互式验证。为了降低验证计算的成本，我们将聚合承诺值等分成十份，每次挑战，质疑者选中其中一份进行挑战，合约只需要进行十次聚合域计算，若被质疑的部分经过合约计算证明是正确的，那么质疑者失败，会被罚没押金；若通过合约计算，发现被质疑的聚合部分确实是存在错误信息，那么质疑者就需要再次把质疑的部分十等份，选中一份发起挑战，直至最终确定到非聚合的错误承诺值，质疑者和验证合约都对故障数据达成了共识，质疑者将获得奖励，导致数据故障的存储节点将接受惩罚。 + +### 总结 + +Meeda通过kzg多项式承诺技术、椭圆曲线计算、数据可用性抽样、纠删码多备份冗余机制、链上验证等技术保障数据的可用性，为以太坊Layer2，尤其是Optimistic类的Rollups，提供了一种安全可靠、低成本的DA解决方案。 + +## 5.9 Lightnode API（轻节点开发者接口） + +可以按照轻节点部署文档中的步骤启动Meeda的轻节点，轻节点提供了普通用户访问Meeda网络所需的一些http API接口。该服务默认监听端口为8082，即baseURL为 https://localhost:8082 ；以下所有请求URL应根据实际情况进行更改。 + +### 1. 上传数据 + +请求Url：`https://localhost:8082/putObject` + +请求方式：POST + +请求头信息： + +| 参数名 | 变量 | +| --- | --- | +| Content-Type | application/json | + +请求参数： + +| 参数名 | 变量 | 类型【长度限制】 | 必填 | 描述 | +| --- | --- | --- | --- | --- | +| data | 待上传的数据 | String | 是 | 将要上传的数据，使用16进制编码表示 | + +返回参数(JSON)： + +| 参数名 | 变量 | 类型【长度限制】 | 必填 | 描述 | +| --- | --- | --- | --- | --- | +| id | 文件ID | string | 是 | 文件唯一标识符 | + +返回例子： + +```json +{"id":"0x1010674e8b5d7167e335fb4f1237fa11857b8f890c0b2051b303e4c9120fc6732962c67309653bf3c80cba3207ddf4d808735fbf50c706b68761ec94b5ef9c00564503621f21eb8513fd2c7a6a2fa5fb548872b3bee34961b888124b0caa92a7"} +``` + +### 2. 下载数据 + +请求Url：`https://localhost:8082/getObject?id={id}` + +请求方式：GET + +请求头信息：无。请求参数：无。 + +返回参数（Data）： + +| 参数名 | 描述 | +| --- | --- | +| contentType | 数据类型 | +| data | 数据二进制值 | + +### 3. 查看文件相关信息 + +请求Url: `https://localhost:8082/getObjectInfo?id={id}` + +请求方式：GET + +请求头信息：无。请求参数：无。 + +返回参数（JSON）： + +| 参数名 | 描述 | +| --- | --- | +| id | 数据唯一ID | +| size | 数据大小 | +| expiration | 数据过期时间 | + +### 4. 查看证明信息 + +请求Url: `https://localhost:8082/getProofInfo?id={id}` + +请求方式：GET + +请求头信息：无。请求参数：无。 + +返回参数（JSON）： + +| 参数名 | 描述 | +| --- | --- | +| id | 数据唯一ID | +| selectedNumber | 数据被抽中参与KZG证明的次数 | +| provedSuccessNumber | 数据被抽中参与KZG证明，且存储节点上传了正确证明的次数 | + +### 5.9.1 How to Connect L2 to Meeda（L2 接入 Meeda） + +Meeda作为适用于以太坊Layer2的数据可用性解决方案，本文将详细讲解L2如何接入Meeda。 + +L2链本质上和L1链没有区别，一样是由虚拟机执行交易后，将结果打包到区块中共识上链。之所以执行的更快，gas开销更低主要是因为节点更少更精了，可以通过调整gas计算参数来降低gasfee。因为DA的接入不会干扰链本身的运行，所以L1和L2链都不需要做任何变动。 + +L2接到L1需要部署一系列的合约，用于完成消息的传递，这也是L2的核心。这些合约在部署后就有固定的地址和相应的事件用于分辨出哪些是与L2L1交互相关的交易。由于DA层的接入只需要修改传递的消息内容，而不影响传递的流程和方式，所以这一块也不需要变动。 + +L2锚定到L1链，以及验证相关的流程需要L2与L1之间有一层负责交互的角色。这些角色主要分为两个，一个是`batcher`，另一个是`node`。前者主要将L2的交易数据打包存放在到L1链上，后者主要是读取L1链上记录的数据，从而获得可在L2上执行的交易内容。显然这两块都与DA层有关，或者说在L2方案上，这两个角色本身就负责与DA相关的内容，也大多独立出了相关的接口方法。DA的接入就需要变动这两块的相关流程。 + +剩余的一些挑战角色、监控和提案者和L2的锚定以及安全性有关，具体参考op，这里不再详述。 + +因此，Rollup接入Meeda，只需要改动`batcher`以及`node`模块的逻辑，应用到Meeda的`submit`和`get`方法即可。 + +**接入Meeda**：下面将简单介绍接入的原理，并以OP为例子介绍Meeda的接入。 + +前提：有正常运作的Layer2，且Layer1正作为DA层，通过`calldata`或`blob`存放来自Layer2的数据。 + +引用DA的client包：`https://github.com/memoio/go-da-client` + +接入方式： + +1. 在项目中引入包后，可以创建一个模块用于初始化client、调用接口，并规定Meeda的识别码。 +2. 在负责读取L1的`calldata`数据并恢复成可被L2执行的交易数据的模块中（如op-stack中的`op-node`），增加在步骤1中构建的模块。在读取到Meeda的识别码时通过client去Meeda层获取到原本的交易数据，后续流程不变。 +3. 在负责将L2的交易数据打包至L1层的模块中（如op-stack中的`op-batcher`），增加在步骤1中构建的模块。在打包完L2交易数据准备封装至L1交易的`calldata`前，通过client将这部分交易数据上传至Meeda层，并将上传成功后返回的定位索引（URI，如CID、MID、commitment等用于定位数据资源的ID符）作为替换封装至L1交易的`calldata`中，后续流程不变。 + +接入对原流程的影响非常小，因为如果在使用Meeda的过程中出现错误，会自动走fallback回到原本的流程中，按原来的流程继续走下去，不需要调整函数的参数和提前退出流程，是noninvasive、nonaggressive的植入。 + +**示例**：以 optimism（https://github.com/memoio/optimism ）为例： + +*步骤1*：引入包后，创建使用Meeda client的模块目录：`op-memo`。内部的`da_client.go`封装了初始化client和调用DA层的接口。内部的`da.go`规定了在`calldata`中表明是Meeda层索引的Meeda识别码。内部的`cli.go`则指定了命令行参数：接入Memo DA服务的RPC地址。 + +*步骤2*：在optimism中读取`calldata`数据并恢复成可被L2执行的交易数据的执行逻辑在`op-node/rollup/derive/calldata_source.go`的`DataFromEVMTransactions`中： + +```golang +// DataFromEVMTransactions filters all of the transactions and returns the calldata from transactions +// that are sent to the batch inbox address from the batch sender address. +// This will return an empty array if no valid transactions are found. +func DataFromEVMTransactions(dsCfg DataSourceConfig, batcherAddr common.Address, txs types.Transactions, log log.Logger) []eth.Data { + out := []eth.Data{} + for _, tx := range txs { + if isValidBatchTx(tx, dsCfg.l1Signer, dsCfg.batchInboxAddress, batcherAddr) { + // Meeda: if the calldata is represented in MemoDerivation marker, then fetch it from Meeda layer + data := tx.Data() + switch len(data) { + case 0: + out = append(out, data) + default: + switch data[0] { + case memo.DerivationVersionMemo: + log.Info("Meeda: blob request", "id", hex.EncodeToString(tx.Data())) + ctx, cancel := context.WithTimeout(context.Background(), daClient.GetTimeout) + blobs, err := daClient.Client.Get(ctx, [][]byte{data[1:]}) + cancel() + if err != nil { + log.Warn("Meeda: failed to resolve frame", "err", err) + log.Info("Meeda: using eth fallback") + out = append(out, data) + } + if len(blobs) != 1 { + log.Warn("Meeda: unexpected length for blobs", "expected", 1, "got", len(blobs)) + if len(blobs) == 0 { + log.Warn("Meeda: skipping empty blobs") + continue + } + } + out = append(out, blobs[0]) + default: + out = append(out, data) + log.Info("Meeda: using eth fallback") + } + } + } + } + return out +} +``` + +在发往`BatchInboxAddress`的交易的`calldata`中读取到Meeda的识别码时（`case memo.DerivationVersionMemo:`）通过client去Meeda层获取到原本的交易数据，后续流程不变。 + +需要在启动时先为`op-node`初始化一个Meeda的client： + +```golang +var daClient *memo.DAClient + +func SetDAClient(c *memo.DAClient) error { + if daClient != nil { + return errors.New("da client already configured") + } + daClient = c + return nil +} +``` + +具体的初始化流程在`op-node`启动时完成，这里不再细述。 + +*步骤3*：在optimism中负责将L2的交易数据打包至L1层的执行逻辑在`op-batcher/batcher/driver.go`的`sendTransaction`中。但这里保持原有的处理流程不变，只在用calldata生成交易时调整一下，即`calldataTxCandidate`： + +```golang +func (l *BatchSubmitter) calldataTxCandidate(data []byte) *txmgr.TxCandidate { + l.Log.Info("building Calldata transaction candidate", "size", len(data)) + + // Meeda: try to submit the data to Meeda layer + ctx, cancel := context.WithTimeout(context.Background(), 30*time.Duration(l.RollupConfig.BlockTime)*time.Second) + ids, err := l.DAClient.Client.Submit(ctx, [][]byte{data}) + cancel() + if err == nil && len(ids) == 1 { + l.Log.Info("Meeda: blob successfully submitted", "id", hex.EncodeToString(ids[0])) + data = append([]byte{memo.DerivationVersionMemo}, ids[0]...) + } else { + l.Log.Info("Meeda: blob submission failed; falling back to eth", "err", err) + } + + return &txmgr.TxCandidate{ + To: &l.RollupConfig.BatchInboxAddress, + TxData: data, + } +} +``` + +在获得待封装的交易数据后，先尝试通过DAClient将数据上传至Meeda层。如果上传没有问题，将返回的定位索引连同Meeda的识别码一起封装并替代原本的交易数据，后续流程不变，将这部分交易数据封装到待打包的L1交易中。如果上传失败，则维持原本的流程，将完整的交易数据封装到待打包的L1交易中。 + +同样地，需要在启动时先为`op-batcher`初始化一个Meeda的client： + +```golang +// DriverSetup is the collection of input/output interfaces and configuration that the driver operates on. +type DriverSetup struct { + Log log.Logger + Metr metrics.Metricer + RollupConfig *rollup.Config + Config BatcherConfig + Txmgr txmgr.TxManager + L1Client L1Client + EndpointProvider dial.L2EndpointProvider + ChannelConfig ChannelConfig + PlasmaDA *plasma.DAClient + DAClient *memo.DAClient +} +``` + +具体的初始化流程在`op-batcher`启动时完成，这里不再细述。 + +### 5.9.2 Deploy OPStack Layer2 with Meeda（用 Meeda 部署 OPStack Layer2） + +本文档提供了使用Meeda作为数据可用性方案，部署OPStack Layer2 Rollup的完整指南。 + +**关键组件**：部署需要以下核心工具： + +- **op-contracts v2.0.0-beta.3**：智能合约框架 +- **op-node (v1.9.4)**：共识客户端 +- **op-geth (v1.101411.0)**：执行客户端 + +**主要部署阶段**： + +- **基础设施准备**：安装 Go、Node.js、pnpm、Foundry 等依赖，随后编译合约。 +- **环境配置**：设置 RPC 端点、链 ID，以及 admin、batcher、proposer、sequencer 各角色对应的账户地址与私钥。 +- **L1 合约部署**：将核心合约部署至 Layer 1 测试网（Sepolia），建立桥接基础设施。 +- **L2 初始化**：生成 Layer 2 链的创世文件与配置文件。 +- **节点运行**：依次启动 op-geth、op-node、op-batcher、op-proposer，并配置相应参数。 + +**主要特性**：配置支持"以 Meeda 作为数据可用性提供方"，相关设置包括 `--altda.enabled=true`，以及指向 Meeda 轻节点的 `--altda.da-server`。 + +文档还说明了常见问题的处理，包括 RPC 服务商的限流问题，以及为避免数据库损坏而需要遵循的正确关闭流程。 + +跨链操作支持从 L1 向 L2 的存款，以及通过 Optimism SDK 实现的提款回 L1。 + +### 5.9.3 Contract（FileProof 合约设计） + +Meeda的验证合约主要由FileProof实现。接下来将具体讲解FileProof的设计细节，以供开发者探讨。 + +**背景**：Layer2节点经过DABackend节点上传文件，Meeda的DA层保证文件的可用性。Layer2节点需要向DABackend节点付费，以维持数据可用性服务。 + +FileProof作为Meeda的数据可用性层，它是Meeda的智能合约部分，充当去中心化的监管者。DABackend节点需要定期往链上提交数据可用性证明，证明通过则可以认为Layer2节点数据的可用性得到保障，DABackend节点从而可以获得相应的服务费用，证明失败，则DABackend节点无法获取相应的服务费用，该笔费用将发放给基金会，用于开发维护更加稳定可靠的服务平台。 + +为了减少数据可用性证明的开销、提高数据可用性证明的效率，FileProof从Layer2中Optimistic Rollup获得灵感，实现了适用于文件可用性证明的乐观验证和多轮交互式欺诈证明方案。并且利用KZG多项式承诺技术，使得验证方式高效且低成本。从而提供一种简洁高效、低成本、可扩展性强、去中心化的DA解决方案。 + +**技术背景**：应用bls12-381曲线和kzg多项式承诺技术。 + +通过多方计算生成一个私密参数s，公开 `ψ=s*g_2`，也就是验证公钥vk；并且公开`s_i = s^i*g_1`。其中，`g_2`是bls12_381曲线的G2生成元，`g_1`是bls12_381曲线的G1生成元。 + +对于要被证明的数据，可以将其看作是向量P: {p0, p1, ... , `p_{n-1}` }，其中pi ∈ Fr，大小不超过32字节，可以将数据分割为32字节的atoms，然后将每一个atom转换为Fr元素。 + +然后将向量P构建成一个多项式 `P(x) = Σ p_i x^i`，之后得到该文件的承诺C，`C = P(s)g_1 = Σ p_i s_i`，C是一个G1点。 + +*证明*：证明者需要提供数据P的持有证明proof。验证者给定一个随机数z（bytes32），数据拥有者也就是证明者可以计算：`y = P(z)`，并且取多项式`Q(x) = (P(x)-y)/(x-z)`。从而计算：`π = Q(s)g_1`。证明proof即为（`y`，`π`）。 + +*验证*：验证者在不知道数据的情况下，即在不知道向量P的情况下，根据公开参数`ψ`、z、y、`π`、`C`，验证证明者确实知道数据。验证者根据bls12_381的线性配对性质，验证`e(π, ψ-z*g_2) = e(C - y*g_1, g_2)`即可，如果验证通过，则可以确定证明者知道数据P，否则证明者不知道数据P。 + +*批量证明*：在同一个随机数z的情况下，证明者提供批量证明。批量生成各个文件的承诺`C_j`以及证明（`y_j`，`π_j`）。验证者依然是验证聚合后的等式关系。 + +**流程**： + +*1. 上传文件* + +链下：Layer2节点上传文件，DABackend节点返回给Layer2节点一个文件已上传的凭证`credential`以及一个文件唯一识别符`commitment`（即由该文件产生的多项式承诺）。其中，`commitment`是一个G1元素，96字节长度，x坐标48字节，y坐标48字节。在合约中用bytes32[4]格式表示一个G1元素的Affine坐标格式，前两个bytes32表示x坐标，后两个bytes32表示y坐标，x、y均为大端编码格式，并且bytes32[2]的最前面16个字节全部填充0。 + +文件已上传的凭据可以是DABackend节点的一个签名，签名内容应包含FileProof的合约地址（以防以后更换合约导致该签名有被重复利用的风险）、Layer2节点地址（上传文件者，即文件拥有者）、文件`commitment`、文件`size`（单位Byte）、文件存储起始时间`start`（用时间戳表示）、文件存储结束时间`end`，文件到期后DABackend节点不需要再提供该文件的可用性证明。获得签名内容后，DABackend节点用私钥进行签名，从而保障文件确实已经成功上传至存储节点，否则，Layer2节点可能会提交一个并未上传的文件`commitment`至合约，DABackend节点后续无法提供该文件的可用性证明，从而受到不应该有的惩罚。 + +签名内容的哈希计算方式：`bytes32 hash = keccak256(abi.encodePacked(fileProofAddr, caller, commitment, sizeByte, start, end));` + +链上：Layer2节点调用合约中的`addFile`方法将文件`commitment`保存到链上，用于后续DABackend节点提供文件可用性证明。合约验证凭据`credential`，验证通过则可以将文件`commitment`保存在合约中（DABackend节点将会定期向合约提交部分文件的可用性证明），并且Layer2节点需要为文件可用性服务付费。费用统一由合约账户保管。服务单价为`price`（单位是attomemo/byte/second，服务费用`value = size * price * (end - start)`），会被记录在合约中，并且可以由基金会成员根据实际情况生成多签进行修改，修改`price`不会影响到已经上传的文件。 + +（之所以规定只提交部分文件的可用性证明，而不是提交全部文件的可用性证明，是因为若规定每次提交全部文件的可用性证明，那么DABackend节点不需要保存文件数据本身，只保存所有文件的多项式参数之和就能应付定期证明提交。而规定每次随机抽查部分文件，则可以使DABackend节点必须保存文件数据，这样才能根据文件以及随机数，生成被随机抽查部分文件的可用性证明，从而通过定期证明提交。） + +Layer2节点无法再次上传一个已经存在的文件`commitment`。每次上传`commitment`时，都需要维护最后有效期`finalExpire`，它表示所有文件都到期的时间。在`finalExpire`后，DABackend节点不再需要提交可用性证明，DABackend节点也不会再获得收益。 + +*2. 提交证明* + +所有上传的文件，其`commitment`以及有效期`end`都保存在链上。针对未到期的文件，DABackend节点需定期往链上提交可用性证明，从而可以获得相应的服务费用。证明通过，则可以视为在一定程度上（抽样检测无法百分百保证）Layer2节点数据的可用性得到保障。 + +*2.1 生成随机数*：根据kzg多项式承诺方案以及去中心化特性，将由合约定期生成一个伪随机数`rnd`，合约将根据`rnd`确定本段时期被抽查的文件，之后，DABackend节点根据`rnd`对被抽查的文件生成可用性证明，合约也根据`rnd`对该证明进行验证。 + +需要保证该伪随机数无法预测，如果随机数能够被预测，那么DABackend节点可以做出恶意行为从而提前知道待验证的文件，进而提前准备可用性证明，而不需要一直完整保存Layer2节点数据，在这种情况下，Layer2节点数据的可用性无法得到可靠的保障。因此，每一段时期内的随机数需要在可以开始提交可用性证明的特定短时期内生成。 + +因此，除了确定提交可用性证明的间隔时间`interval`外，还需要确定一个提交证明的有效时期`period`。每隔一段时间`interval`，DABackend节点需要在有效时期`period`内提交证明。DABackend节点在有效时期`period`内未提交证明，则可以视为DABackend节点在该段时期`interval`内未履行保障Layer2节点数据可用性的协议，DABackend节点则无法获取该段时间的服务收益。 + +DABackend节点每次提交可用性证明需要用到的随机数`rnd`，也只能在间隔时间`interval`后、有效时期`period`内生成，一旦生成，在该段时期`period`内不可更改，超过了有效时期`period`，该随机数`rnd`将失效。 + +DABackend节点提交证明的间隔时间`interval`以及提交证明的有效期`period`由基金会成员讨论决定，在部署合约时指定，且后续可根据实际情况进行更改。 + +*2.2 挑选待验证文件*：在提交证明的有效时期`period`内，合约才会生成此次的有效随机数`rnd`，根据该随机数`rnd`再确定挑选哪些文件进行验证。DABackend节点需要生成这些文件的可用性证明并聚合，之后将聚合证明提交到合约中进行验证（将采取乐观和多轮交互的方式进行验证）。 + +DABackend节点需要保证和合约使用相同的算法来获取待验证文件，或者直接从合约提供的接口进行查询，否则验证将总是失败。每次挑选的文件总数由`chalSum`指定，`chalSum`是根据系统中的文件总数经过一定的概率计算得出的。这里暂时不考虑系统中已过期的文件数，后期Meeda将考虑到这个情况，使得该解决方案更加简洁高效。 + +查询该段时期哪些文件被挑选的功能由合约中的接口`selectFiles(uint i)`实现。由`rnd`、文件总数`length`以及待挑选文件的索引`i`[0, chalSum)，得到将要被挑选的文件的承诺值（如果被选中的文件已过期，那么承诺值为0），根据kzg多项式承诺，对被选中的文件生成相应的可用性证明，将所有可用性证明聚合得到`Pn`，将被选中文件的commitments聚合得到`Cn`。 + +上次提交证明时间记为`last`，那么这次提交证明的截止时间则为`last+interval+period`。每个验证期挑选文件时，文件存储结束时间`end`不超过`last`的，都视为已到期文件。 + +*2.3 生成证明并提交*：DABackend节点在链下获得被挑选的待验证文件的数据持有证明，聚合这些证明，将聚合证明`Pn`和聚合承诺`Cn`提交到链上。DABackend节点需要保证使用的随机数是有效的，即和合约中生成的有效随机数一致。 + +乐观验证即假设DABackend节点提交的`Cn`（被挑选文件的聚合承诺）是正确的，只需要验证`Pn`对`Cn`的正确性即可。在规定的有效期内，若没有节点（任意节点）提出对`Cn`的质疑，那么该次可用性证明则视为成功。如果有节点提出质疑，该节点就往链上发起挑战（该节点被称为挑战者），后续则触发多轮交互验证`Cn`的正确性，验证通过，该次可用性证明才被视为成功。 + +如果DABackend节点提交的证明`Pn`通过验证，那么本次验证期（也就是``）应获得的服务收益`thisProfit = balance * (last_now - last_pre) / (finalExpire - last_pre)`，其中`balance`表示合约账户的有效余额（Layer2节点上传文件时将服务费用交由合约账户保管，每次提交可用性证明时线性释放给DABackend节点）。为了支持代价更小的多轮交互式验证方式并且激励DABackend节点提供更好的服务，服务收益采取延期释放的方式。也就是说，本次提交可用性证明应获得的收益将会在下一次提交证明时释放。无论本次可用性证明的验证是否通过，合约账户都会将上一次提交可用性证明时应得的收益释放给DABackend节点。 + +*3. 欺诈证明* + +DABackend节点定时提交可用性证明后，为了减少验证的代价，采用了乐观验证方式。即只针对聚合承诺`Pn`进行验证，若失败，则直接表明本次验证失败；若成功，则任意节点可以选择进一步对`Cn`提出质疑。因为第一阶段只是假设DABackend节点不存在欺诈行为，也就是假设`Cn`是正确的。如果任意节点在链下计算的过程中发现`Cn`是错误的，则可以在链上提出对`Cn`的质疑，从而发起挑战。挑战成功，则挑战者获得经济奖励；挑战失败（也就是说`Cn`确实是正确的），则挑战者将失去挑战时质押的资金。节点提出质疑并发起挑战最终得到挑战结果的这一过程就称为欺诈证明。 + +第一阶段是证明`Pn`对`Cn`的正确性，第二阶段的欺诈证明就是证明`Cn`的正确性。为了减少链上的计算量，并且提高对文件抽样检查的覆盖率，采用Arbitrum式的多轮交互验证模式。 + +*3.1 提出质疑*：DABackend节点提交证明后，将进行第一阶段的证明验证。根据验证公钥`vk`，验证聚合承诺`Cn`、聚合证明`Pn`以及有效随机数`rnd`是否存在有效的配对关系。 + +无论本轮验证是否通过，都会将上一次提交证明的收益释放给DABackend节点（为了保障资金安全，DABackend节点可以设置一个专用于接收资金的冷账户地址`receiver`）。 + +如果验证失败，则本次提交证明的收益直接为0。如果验证成功，则先将本次的收益记录下来，等到下一次提交证明时再释放。如果有节点提出质疑，则开启第二阶段，该节点发起挑战，触发欺诈证明，目的是证明DABackend节点存在欺诈行为，如果欺诈行为确实存在，那么本次的收益也会被扣掉（一部分奖励给挑战者，一部分奖励给基金会）。 + +*3.2 多轮交互*：节点可以自行选择是否要发起挑战，如果挑战失败（DABackend节点不存在欺诈行为），那么挑战者将白白浪费掉自己的交易费和质押费用（发起挑战时需要质押挑战费）；如果挑战成功（DABackend节点确实存在欺诈行为），那么挑战者将获得回报。这一机制有效减少了文件可用性证明的代价，并且有效遏制了欺诈行为。 + +当挑战发起后，DABackend节点需要在有效期`respondTime`内进行响应，若没有在有效期内响应，则视为DABackend节点失败，表明DABackend节点存在欺诈行为。DABackend节点若要正常响应，则需要将被挑选的待验证文件按顺序分成十等份，每一份文件的承诺值进行聚合，得到10个聚合承诺值`_cns`，调用`responseChal`方法将`_cns`提交到链上合约中，在合约中进行聚合验证，合约将`_cns`再次聚合，验证其是否和第一阶段中提交的`cn`一致。若一致，则说明在此轮交互中，没有发现DABackend节点的欺诈行为；若不一致，则可以直接证明DABackend节点存在欺诈行为。 + +若在第一轮交互中没有发现DABackend节点的欺诈行为，那么挑战者可以在`respondTime`内选择发起第二轮交互，具体为：挑战者调用`continueChal`方法，在上一轮的`_cns`中选择一个有问题的聚合承诺值`_cn`，也就是把有问题的文件范围压缩了10倍（用`chalIndex`表示十等份文件中的第几份），针对该部分文件继续挑战DABackend节点。DABackend节点接收到`continueChal`的信号后，仍然需要在`respondTime`内进行响应，继续将`chalIndex`表示的文件按顺序分成十等份，之后的逻辑和上述相同。 + +一旦发起挑战，DABackend节点和挑战者任一方，没有在有效期`respondTime`内进行响应，都将被视为失败方。 + +*3.3 单步证明*：直到最后一轮交互，被挑战的文件范围被压缩至只有几个，此时不需要聚合文件，只需要提交这几个文件的单个承诺值即可。该过程被称为单步证明。DABackend节点只需要调用`oneStepProve`方法，将单个文件的承诺值提交到合约中，合约先验证这些文件的聚合承诺值是否与上一轮的承诺值一致，之后再将这些文件的承诺值一一与链上记录的该文件承诺值进行比对，如果比对成功，则可以最终表明DABackend节点不存在欺诈行为，挑战者将为他的恶意挑战付出代价；如果比对不成功，则表明DABackend节点存在欺诈行为，挑战者将获得回报。 +### 5.9.4 FileProof API（合约方法详解） + +FileProof是Meeda DA层的合约实现。 + +**1. addFile** + +`function addFile(bytes32[4] memory commitment, uint64 sizeByte, uint256 start, uint256 end, bytes memory credential)` + +功能：账户将文件commitment和其他元数据信息添加到合约中，并预付文件可用性服务费用。 + +注意：调用该方法前，账户需要先`approve`FileProof合约账户相应的费用，费用价格为：sizeByte*(end-start)*price。 + +参数：`commitment`（文件唯一标识符，是文件的kzg承诺）、`sizeByte`（文件大小，单位Byte）、`start`（文件上传时间）、`end`（文件存储结束时间）、`credential`（文件上传凭据，表明文件确实已上传到da-backend）。 + +事件：`event AddFile(address indexed account, bytes32[4] indexed commitment, uint256 start, uint256 end, uint64 size, uint64 price);`、`event Transfer(address indexed from, address indexed to, uint256 value);` + +**2. genRnd** + +`function genRnd()` + +功能：产生一个伪随机数用于提交证明以及验证。 + +注意：只有在正确的时间调用才能产生有效的伪随机数。当不是最后一个挑战期（`finalExpire > last+interval+period`）时，正确的时间处于<`last+interval`, `last+interval+period`>之间；当处于最后一个挑战期（`finalExpire <= last+interval+period`）时，正确的时间处于<`finalExpire`, `finalExpire+period`>之间。 + +事件：`event GenRnd(bytes32 rnd);`、`event NoProofs(uint256 oldLast, uint256 newLast, uint256 missedProfit);` + +**3. submitProof** + +`function submitProof(bytes32 _rnd, bytes32[4] memory _Cn, ProofInfo memory _Pn)` + +功能：submitter提交聚合证明，并且进行第一阶段的验证，验证`Pn`的正确性。 + +注意：每个时期（<`last`, `last+interval+period`>期间称为一个时期）只能在产生有效随机数之后提交一次证明，即使该证明错误也无法再次提交去弥补。无论本次证明验证是否成功，都会释放上一时期的收益。若本次证明验证成功，则暂定本次收益为合约账户剩余余额对总时间的线性释放（`thisProfit = balance * (interval+period) / (finalExpire - last)`），之所以说是暂定，是因为可能有节点会发起挑战，从而开启第二阶段验证，在第二阶段验证中，可能会发现da-backend存在欺诈行为。若存在欺诈行为，则本次收益为0。 + +参数：`_rnd`（调用genRnd()后产生的有效随机数）、`_Cn`（待验证文件的聚合承诺）、`_Pn`（待验证文件的聚合kzg证明）。 + +可用性证明proof结构体定义如下： + +```sol +struct ProofInfo { + bytes32[4] npsi; // G1, (x,y), x:bytes48(represented by bytes32[2]), y:bytes48 + bytes32 y; // Fr +} +``` + +事件：`event SubmitProof(bytes32 indexed rnd, bytes32[4] cn, ProofInfo pn, bool res);`、`event ProfitRelease(uint256 releasedProfit, uint256 lockedProfit, uint256 missedProfit);`、`event Transfer(address indexed from, address indexed to, uint256 value);` + +**4. doChallenge** + +`function doChallenge(uint8 _chalIndex)` + +功能：任意账户发起挑战，开启第二阶段验证，验证`Cn`的正确性。 + +参数：`_chalIndex`（指定被等分后的多个聚合承诺值的索引`Cn_i`，第一轮挑战`_chalIndex`为0）。 + +注意：发起挑战的时候，挑战者需要进行质押，从而防止恶意挑战行为。若挑战成功，质押将被返回；若挑战失败，质押将被扣除。发起挑战前，挑战者需要先`approve`FileProof合约账户质押费用（SettingInfo.chalPledge）。 + +事件：`event CreateChal(bytes32 indexed rnd, bytes32[4] cn, uint256 chalPledge, address challenger)`、`event Transfer(address indexed from, address indexed to, uint256 value);` + +**5. responseChal** + +`function responseChal(bytes32[4][10] memory _cns)` + +功能：submitter响应挑战。 + +参数：`_cns`（将被挑战的`Cn`等分）。 + +注意：响应挑战失败（也就是_cns聚合不能得到正确的`Cn`）的情况下，将触发事件。 + +事件：`event Fraud(bytes32 indexed rnd, address indexed submitter, address indexed challenger, uint256 fine, uint256 reward);`、`event Transfer(address indexed from, address indexed to, uint256 value);` + +**6. oneStepProve** + +`function oneStepProve(bytes32[4][] memory _commitments)` + +功能：submitter提交最后一轮的单步证明，从而响应最后一轮的挑战。 + +参数：`_commitments`（被挑战的`Cn`的多个文件承诺值）。 + +注意：响应挑战失败（也就是_commitments聚合不能得到正确的`Cn`）的情况下，将触发`Fraud`事件；否则，将触发`NoFraud`事件。 + +事件：`event Fraud(...)`、`event NoFraud(bytes32 indexed rnd, address indexed submitter, address indexed challenger, uint256 compensation);`、`event Transfer(...)` + +**7. endChallenge** + +`function endChallenge()` + +功能：当submitter没有及时响应挑战，或者挑战者没有及时发起下一轮的挑战，任何账户都可以调用该方法，从而结束挑战。 + +注意：submitter没有及时响应挑战的情况下，将触发`Fraud`事件；否则，将触发`NoFraud`事件。 + +**8. withdrawMissedProfit** + +`function withdrawMissedProfit()` + +功能：任何账户可以调用该方法，从而将错失收益转给基金会账户。错失收益即submitter未按时响应挑战，或者在第一阶段提交证明的时候就失败的情况下，错失的收益。 + +事件：`event Transfer(address indexed from, address indexed to, uint256 value);` + +**9. alterSetting** + +`function alterSetting(IFileProof.SettingInfo memory si, bytes[5] memory signs)` + +功能：社区成员根据实际情况，获取多签，从而修改FileProof基本配置。 + +参数：`si`（新的配置信息）、`signs`（社区成员的多签信息）。 + +`SettingInfo`结构体定义如下： + +```sol +struct SettingInfo { + uint32 interval; // the interval of submitProof, unit: s + uint32 period; // the period of submitProof, unit: s + uint32 chalSum; + uint32 respondTime; // effective respond time for each step in the multi-round interaction process + // size price(attomemo/byte/second), used to calculate the addFile fee based on the file size + uint64 price; + address submitter; // who submit proofs to get rewards + address receiver; // submitter specifies the receiver receives rewards + address foundation; // receive the missedProfit + uint8 chalRewardRatio; // the ratio of pendingProfit to be rewarded to challenger when submitter is indeed fraudulent + uint256 chalPledge; // the amount that should be staked when create challenge + bytes32[8] vk; // verifyKey, s * g_2, mpc -> s; G2, x:bytes96(two Fp elements, represented by bytes32[4]), y:bytes96 + } +``` + +事件：`event AlterSetting(SettingInfo si);` + +**10. selectFiles**：`function selectFiles(uint256 i) external view returns (bytes32[4] memory commitment)` —— 每个时期产生有效随机数后，合约会根据随机数挑选一批待证明的文件，输入这批文件的索引，从而返回对应的文件承诺值。被挑选文件的总数由`SettingInfo.chalSum`决定。 + +**11. getCommit**：`function getCommit(uint256 i) external view returns (uint256 sum, bytes32[4] memory commitment)` —— 根据序号，获取合约中上传文件的总数和对应的承诺值。 + +**12. getFileInfo**：`function getFileInfo(bytes memory commit) external view returns (uint64 index, uint256 expiration)` —— 根据文件承诺值，获取文件的序号以及到期时间。 + +**13. getProofInfo**：`function getProofInfo() external view returns (bytes32 y)` —— 获取当前时期的证明信息。可通过监控event获取历史证明信息，以及当前完整的证明信息。 + +**14. getVerifyInfo**：`function getVerifyInfo() external view returns (bytes32 rnd, bool lock, uint256 last)` —— 获取当前时期的验证信息。可通过监控event获取历史验证信息。 + +**15. getProfitInfo**：`function getProfitInfo() external view returns (uint256 pendingProfit, uint256 missedProfit, uint256 finalExpire)` —— 获取当前时期的收益信息。可通过监控event获取历史收益信息。 + +**16. getChallengeInfo**：`function getChallengeInfo() external view returns (uint8 chalStatus, address challenger, uint8 chalIndex, uint256 startIndex, uint256 chalLength)` —— 获取当前时期的挑战信息。 + +**17. getSettingInfo**：`function getSettingInfo() external view returns (uint32 interval, uint32 period, uint32 chalSum, uint32 respondTime, uint64 price, address submitter, address receiver, address foundation, uint8 chalRewardRatio, uint256 chalPledge)` —— 获取当前的配置信息。 + +**18. getVK**：`function getVK() external view returns (bytes32[8] memory vk)` —— 获取当前的验证公钥。 + +### 5.9.5 FileProof Contract Address（合约地址） + +**chain: memo product** + +| Contract | Address | +| --- | --- | +| FileProof | 0x58C3Ab98546879a859EDBa3252A9d38E43C9cbee | +| ControlFileProof | 0x6eEc7578dBAD9dcc1CA159A9Df0A73233548b89a | +| ProxyFileProof | 0x0c7B5A9Ce5e33B4fa1BcFaF9e8722B1c1c23243B | +| Instance | 0xbd16029A7126C91ED42E9157dc7BADD2B3a81189 | + +**chain: memo dev** + +| Contract | Address | +| --- | --- | +| FileProof | 0x7bf3C03fda919e4CfbB1FD79E815FAa51755720d | +| ControlFileProof | 0x6C3F60480e7246EaE194f3F6512E49b392B76D7c | +| ProxyFileProof | 0xBC2BB92F589f332F07f7aE06d0f5080870CE0467 | +| Instance | 0x10790c26fB42AaDB87c10b91a25090AF1Ff5352E | + +合约代码（目前暂未公开）：https://github.com/memoio/did-solidity/tree/memoda 经`abigen`转化的合约go代码位于 https://github.com/memoio/did-solidity/tree/memoda/go-contracts + +用户通过`FileProofProxy`合约地址，构造`FileProofProxy`合约实例，直接调用`FileProofProxy`合约实例，从而与`FileProof`合约交互。 + +## 5.10 How to Build Lightnode（轻节点搭建指南） + +### 安装 + +本文档将指引您如何安装Meeda轻节点。 + +**通过源码安装**：安装轻节点包括以下几个步骤： + +1. 先删除所有的本地依赖库以及meeda-node，并再次下载所有的依赖库以及meeda-node。 + + ```bash + cd $HOME + ### 删除所有的本地依赖库和meeda-node + rm -rf meeda-node did-solidity go-did memov2-contractsv2 go-mefs-v2 relay memo-go-contracts-v2 + ### 获取依赖包 + git clone https://github.com/memoio/did-solidity.git + git clone https://github.com/memoio/did-go-sdk.git + git clone https://github.com/memoio/memov2-contractsv2.git + git clone https://github.com/memoio/go-mefs-v2.git + git clone https://github.com/memoio/mefs-relay.git + git clone https://github.com/memoio/memo-go-contracts-v2.git + ### 将依赖包切换到最新分支(go-mefs-v2) + cd go-mefs-v2 + git checkout 2.7.4 + cd .. + ## 将依赖包切换到最新分支(did-solidity) + cd did-solidity + git checkout meeda-v1.2.0 + cd .. + ## 将依赖包切换到最新分支(did-go-sdk) + cd go-did + git checkout meeda-v2.0.2 + cd .. + ### 获取meeda-node + git clone https://github.com/memoio/meeda-node.git + cd meeda-node + ### 切换到最新分支 + git checkout 1.2.0 + ``` +2. 编译meeda-node： + ```bash + CGO_ENABLED=1 make build + ``` +3. 安装meeda-node： + ```bash + make install + ``` +4. 检查meeda-node是否安装成功： + ```bash + meeda version + ``` + 该命令会输出当前meeda-node的版本信息，commit信息以及编译日期。 + +您已经安装完成轻节点，现在您需要部署轻节点从而接入Meeda的数据可用性网络。 + +### 部署 + +Meeda轻节点会验证Meeda存储全节点提交的KZG证明，若Meeda轻节点验证KZG证明有误，则Meeda轻节点发起多轮挑战，直到一方胜出。 + +通过Meeda轻节点，普通用户可访问和接入Meeda数据可用性网络。Meeda轻节点包括以下功能：上传下载数据；同步上传的数据信息，包括数据承诺，数据大小，数据过期时间等；同步KZG聚合证明信息；验证KZG聚合证明信息，如发现证明有误，则发起多轮挑战。 + +普通用户部署轻节点后，可以从多轮挑战中获取收益。 + +**运行Meeda轻节点**：启动Meeda轻节点时需要设置`sk`参数。`sk`用于轻节点签署以太坊上的交易。Meeda轻节点部署完成后，轻节点的rpc接口将绑定到8082端口。 + +部署在product链上： + +```bash +meeda light run --sk= +``` + +部署在dev链上： + +```bash +meeda light run --chain=dev --sk= +``` + +**关闭Meeda轻节点**：为了正常停止轻节点，请在节点运行的终端中使用`Control + C`命令。 + +### 5.10.1 Layer2+Meeda（L2 接入 Meeda 的可行性） + +这里将简要介绍L2接入Meeda作为其数据可用性解决方案的可行性。 + +**L2概述**：以Layer2中的Optimistic Rollup方案为例，简单概括L2： + +1. 将OP链作为执行层，所有的交易都在该链上执行。因为OP链节点更优质（少而精），因此同步与执行的速度相比于L1链如以太坊会快得多。而本质上链的原理和结构与L1没有太大区别。 +2. 但因为L2的节点少，因此其安全性或者说去中心化程度远远不及L1链。为了保证L2链上的交易安全，需要将L2链上的交易执行结果锚定到L1链上，以获取与L1链相同的安全性与可信度。而这个执行结果就是执行完交易后的状态根。 +3. 虽然通过锚定到L1链上的L2状态根可以认为该L2状态已经被确认，不再可更改，但该L2根是否为有效且诚实的状态根仍不可知，恶意节点可以上传对自己有利的或篡改过的状态根。为了保证根的有效性，L2-OP采用fault-proof的方式，通过提交证明的方式惩罚恶意节点，奖励挑战节点。其中包括乐观假设（挑战周期内有节点做验证）、抽样验证（2D-RScode来提升验证效率）等其他细节不再赘述。 +4. 最后的关键问题在于**数据可用性**。如果在L2上的交易数据被节点扣留，那即使有fault-proof的验证机制，也缺乏原始的交易数据用于验证和挑战欺诈行为。为了保证数据可得，OP的做法是将一大块的L2交易打包，最后提交一笔L1交易到L1链上，L2交易的数据此时都存放在L1交易的`calldata`字段内。这样既保证了数据副本在L1链上，任何节点都能获取到这些数据对L2做验证，而不存在数据扣留的问题；也避免了L1链的执行开销，因为这些`calldata`只是把数据上链，而不参与执行，这些数据对应的交易的真正执行是在L2链上。 + +**L2与Meeda**：至此，OP方案作为Layer2的扩展方案，已经能够安全可靠的对Layer1进行扩展，提升吞吐量并降低交易费开销。但其仍存在一个问题：无法降低数据的同步开销和存储开销。原始的交易数据仍然需要提交到L1链上，L1上的全节点仍需要同步这些交易数据。即使有一些别的方案（如ERC-4337）来压缩部分交易数据，但效果仍旧有限。最直观的体现就是，这些交易数据存放在L1链上仍需要支付高昂的gas费用，尽管这些费用是字节费用而非执行费用。 + +究其根本，还是因为Layer2-OP将以太坊L1链当作自己的DA层（Data Availability，数据可用性）。而Meeda将数据放在链下存储，获取数据用的索引和保证数据可靠性的承诺证明放在链上存储。在保证了数据可用性的同时，也降低了链上的同步开销和存储开销，最大程度扩展区块链。且由于Meeda是独立出来的一层，外部接入只需要使用其`get`和`submit`的接口，而保证数据安全性则依靠Meeda层对应的挑战与验证机制，因此Meeda的接入也非常简洁高效，可以兼容任何的Layer2链。 + +## 5.11 Storage（MEMO 存储中间件 API） + +MEMO 存储中间件为开发者、企业、个人用户等提供一个可扩展、私密性、可靠可用性并且具有可组合性的存储平台，用户可以灵活选择适合自己的底层存储系统，目前支持去中心化存储系统IPFS以及分散式存储系统MEFS。除此之外，MEMO存储中间件还给用户提供了一个文件市场，用户可以在该市场中自由交易个人文件的读取权限，还可以通过关键字等描述信息检索文件。 + +启动中间件服务，默认监听端口为8080。 + +### 登录验证 + +中间件使用[DID](https://www.w3.org/TR/did-core/)作为账号进行登录，DID是一种新型标识符，可实现可验证、去中心化的数字身份。更具体的，我们使用 Memo DID（https://github.com/memoio/did-docs/blob/master/memo-did-design.md ）作为存储中间件的账号。因此用户在登录之前需要首先创建Memo DID并添加验证方法，关于Memo DID的操作详情请参考 did-go-sdk（https://github.com/memoio/did-go-sdk ）以及 did-js-sdk（https://github.com/memoio/did-js-sdk ）。 + +**1.1 登录**：登录的目的是为了对随机字符串token（用户自己生成）达成一致，同时重置requestID为0，通过对token以及递增的requestID进行签名，从而能够调用受限制的HTTP API接口。登录需要在签名后1分钟内完成。 + +请求URL：`http://localhost:8080/login`；请求方式：POST；请求头信息：无。 + +请求参数： + +| 参数名 | 变量 | 类型【长度限制】 | 必填 | 描述 | +| --- | --- | --- | --- | --- | +| did | MEMO DID | String | 是 | 登录所需ID | +| token | 随机字符串 | String | 是 | 用户自己生成的随机字符串(16进制表示) | +| timestamp | 时间戳 | int64 | 是 | 用户签名时时间戳 | +| signature | 签名 | string | 是 | 对上述参数的签名 | + +返回参数："Login success!" + +请求示例（获取签名信息并发起请求的代码）： + +```go +package main + +import ( + "bytes" + "encoding/binary" + "encoding/json" + "flag" + "io/ioutil" + "log" + "net/http" + "time" + + "github.com/ethereum/go-ethereum/common/hexutil" + "github.com/ethereum/go-ethereum/crypto" +) + +func main() { + secretKey := flag.String("sk", "", "the sk to signature") + did := flag.String("did", "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96", "the did to login") + token := []byte("memo.test") + + req, err := GetLoginRequest(*did, token, *secretKey) + if err != nil { + panic(err.Error()) + } + + client := &http.Client{Timeout: time.Minute} + res, err := client.Do(req) + if err != nil { + panic(err.Error()) + } + defer res.Body.Close() + + body, err := ioutil.ReadAll(res.Body) + if err != nil { + panic(err.Error()) + } + + if res.StatusCode != http.StatusOK { + log.Printf("respond code[%d]: %s\n", res.StatusCode, string(body)) + } else { + log.Println(string(body)) + } +} + +func GetLoginRequest(did string, token []byte, privateKeyHex string) (*http.Request, error) { + var url = "http://localhost:8080/login" + var timestampBuf = make([]byte, 8) + var timestamp = time.Now().Unix() + + privateKey, err := crypto.HexToECDSA(privateKeyHex) + if err != nil { + return nil, err + } + + binary.LittleEndian.PutUint64(timestampBuf, uint64(timestamp)) + hash := crypto.Keccak256([]byte(did), token, timestampBuf) + signature, err := crypto.Sign(hash, privateKey) + if err != nil { + return nil, err + } + + var payload = make(map[string]interface{}) + payload["did"] = did + payload["token"] = hexutil.Encode(token) + payload["timestamp"] = timestamp + payload["signature"] = hexutil.Encode(signature) + + b, err := json.Marshal(payload) + if err != nil { + return nil, err + } + + req, err := http.NewRequest("POST", url, bytes.NewReader(b)) + return req, err +} +``` + +错误码： + +| HTTP状态码 | 错误码 | 错误描述 | +| --- | --- | --- | +| 401 | Authentication | Missing paramenter; | +| 500 | InternalError | We encountered an internal error, please try again. | + +**1.2 获取登录信息**：用户在成功登录后，能够获取登录的信息，包括token，requestID以及上次登录时间戳。 + +请求URL：`http://localhost:8080/login?did={did}`；请求方式：GET。 + +返回参数： + +| 参数名 | 变量 | 类型【长度限制】 | 描述 | +| --- | --- | --- | --- | +| token | 随机字符串 | String | 用户自己生成的随机字符串(16进制表示) | +| timestamp | 时间戳 | int64 | 用户签名时时间戳 | +| requestID | 请求ID | string | 用户的请求ID，每次访问受限的HTTP API接口时需要带上请求ID，每次递增 | + +**1.3 访问受限的HTTP API接口**：用户在成功登录后，需要通过签名的方式访问受限的HTTP API接口。每次访问受限的HTTP API接口，除了需要添加原接口所需的请求参数外，还需要添加如下的请求参数： + +| 参数名 | 变量 | 类型【长度限制】 | 必填 | 描述 | +| --- | --- | --- | --- | --- | +| did | MEMO DID | String | 是 | 登录所需ID | +| token | 随机字符串 | String | 是 | 用户自己生成的随机字符串(16进制表示) | +| requestID | 请求ID | int64 | 是 | 用户的请求ID，每次递增 | +| payload | 文件内容hash | string | 否 | 该参数只有在上传文件时提供，等于文件内容hash | +| signature | 签名 | string | 是 | 对上述参数的签名 | + +以查询文件列表接口为例，获取签名信息并发起请求的代码如下： + +```go +package main + +import ( + "bytes" + "encoding/binary" + "encoding/json" + "flag" + "io/ioutil" + "log" + "net/http" + "time" + + "github.com/ethereum/go-ethereum/common/hexutil" + "github.com/ethereum/go-ethereum/crypto" +) + +func main() { + secretKey := flag.String("sk", "", "the sk to signature") + did := flag.String("did", "did:memo:d687daa192ffa26373395872191e8502cc41fbfbf27dc07d3da3a35de57c2d96", "the did to login") + token := []byte("memo.test") + + for index := 0; index < 5; index++ { + req, err := GetVerifyIdentityRequest(*did, token, int64(index), *secretKey) + if err != nil { + panic(err.Error()) + } + + client := &http.Client{Timeout: time.Minute} + res, err := client.Do(req) + if err != nil { + panic(err.Error()) + } + defer res.Body.Close() + + body, err := ioutil.ReadAll(res.Body) + if err != nil { + panic(err.Error()) + } + + if res.StatusCode != http.StatusOK { + log.Printf("respond code[%d]: %s\n", res.StatusCode, string(body)) + } else { + log.Println(string(body)) + } + } +} + +func GetVerifyIdentityRequest(did string, token []byte, requestID int64, privateKeyHex string) (*http.Request, error) { + var requestIDBuf = make([]byte, 8) + var url = "http://localhost:8080/mefs/listobjects" + + privateKey, err := crypto.HexToECDSA(privateKeyHex) + if err != nil { + return nil, err + } + + binary.LittleEndian.PutUint64(requestIDBuf, uint64(requestID)) + hash := crypto.Keccak256([]byte(did), token, requestIDBuf) + signature, err := crypto.Sign(hash, privateKey) + if err != nil { + return nil, err + } + + var payload = make(map[string]interface{}) + payload["did"] = did + payload["token"] = hexutil.Encode(token) + payload["requestID"] = requestID + payload["signature"] = hexutil.Encode(signature) + + b, err := json.Marshal(payload) + if err != nil { + return nil, err + } + + req, err := http.NewRequest("GET", url, bytes.NewReader(b)) + return req, err +} +``` + +### 获取流量支票hash + +用户获取空间支票的hash，用户进行签名后，用于上传。 + +请求URL：`http://localhost:8080/traffichash`；请求方式：GET。 + +请求头信息：`Content-Type: multipart/form-data`；`Authorization: "Bearer 登录验证产生的access token"`。 + +请求参数：`size`（支票大小，String，必填，为累计大小）。 + +返回参数（JSON）：`hash`（支票hash，string）。 + +### 文件上传 + +用户登录后，可上传文件。MEFS采用对象存储，文件默认上传至与登录账户地址同名的bucket中，账户上传文件时，若还未创建同名bucket，中间件则会自动帮用户创建同名bucket。 + +上传文件受用户的剩余可用存储空间限制。用户上传前可查看存储空间单价（单位：attomemo/Byte），购买存储空间，存储空间时限默认是3年。用户也可以向管理员申请免费空间（比如说发指定内容的twitter），管理员接收到申请后给用户发放免费的存储空间。 + +请求URL：选择上传至mefs：`http://localhost:8080/mefs/`；选择上传至ipfs：`http://localhost:8080/ipfs/`。请求方式：POST。 + +请求头信息：`Content-Type: multipart/form-data`；`Authorization: "Bearer 登录验证产生的access token"`。 + +请求参数：`file`（待上传的文件，File，必填）；`size`（支票大小，String，必填）；`sign`（支票签名，String，必填）。 + +返回参数(JSON)：`cid`（上传文件CID，string）。 + +返回例子： + +```json +Response：Status 200 +{ + "cid": "bafybeie2ph7iokrckc5iy6xu7npa4xqst6ez5ewb7j2igeilxjaw6sd2qi" +} +``` + +错误码： + +| HTTP状态码 | 错误码 | 错误描述 | +| --- | --- | --- | +| 401 | Authentication | Token is Null; Invalid token payload; Invalid token; | +| 500 | InternalError | We encountered an internal error, please try again. | +| 518 | Storage | storage not support | + +### 文件下载 + +用户根据文件的etag下载相应的文件。 + +请求URL：选择从mefs下载：`http://localhost:8081/mefs/{cid}`；选择从ipfs下载：`http://localhost:8081/ipfs/{cid}`。请求方式：GET。 + +请求参数：`size`（支票大小，String，必填）；`sign`（支票签名，String，必填）。 + +返回参数（DataFromReader）：返回文件，包含`code`（状态码，200）、`contentLength`（文件大小）、`contentType`（文件类型）、`reader`（io.Reader，文件传输缓冲区）。 + +错误码： + +| HTTP状态码 | 错误码 | 错误描述 | +| --- | --- | --- | +| 500 | InternalError | We encountered an internal error, please try again. | +| 518 | Storage | storage not support | +| 517 | Address | address is null | + +### 文件删除 + +删除上传的文件。仅支持MEFS类型存储的删除功能。 + +请求URL：`http://ip:port/mefs/delete`；请求方式：GET。 + +请求头信息：`Authorization`（"Bearer 登录验证产生的accessToken"，若过期，可通过刷新accessToken来获得新的有效accessToken）。 + +请求参数：`id`（文件id，文件列表中的序号，必填）。 + +返回参数（JSON）：`Status`（删除成功或失败）。 + +### fileDNS + +中间件基于Mfile DID（http://132.232.87.203:8088/did/docs/blob/master/mfile-did设计.md ）实现文件的权限控制，允许用户自我控制文件的权限。同时，会将生成Mfile DID的文件上架到fileDNS上，允许其他用户购买文件的使用权，从而实现创作者通过 Mfile DID 盈利的目的。 + +- **上传至fileDNS**：未提供http-api接口，可通过 did-js-sdk 或 did-go-sdk 上传至fileDNS。 +- **授权读取权限**：未提供http-api接口，可通过 did-js-sdk 或 did-go-sdk 授权读取权限。 +- **购买读取权限**：未提供http-api接口，可通过 did-js-sdk 或 did-go-sdk 购买读取权限。 +- **修改DNS中的file信息**：未提供http-api接口，可通过did-js-sdk或did-go-sdk修改file信息，包括：修改文件所有者；修改文件类型（0表示私有，1表示公开）；修改文件价格（单价为attomemo）；修改文件的关键词。 + +**获取DNS中的file信息**：文件上传至fileDNS后（通常需要等待几分钟），其他用户能够从fileDNS中搜索对应的文件。用户首先输入查询消息，随后中间件会比对文件名以及文件的关键词，从而查找到相关的文件。 + +请求URL：`http://localhost:8080/challenge?query={query_text}&page={page}&size={page_size}`；请求方式：GET。 + +返回参数（Array）：`Mid`（文件的唯一ID）、`Name`（文件名）、`Size`（文件大小）、`Public`（文件是否可以免费获取）、`Price`（读取文件所需的价格）、`keywords`（文件描述的关键词，[]string）。 + +### 查询信息 + +**查询文件列表**：用户查询自己所上传的文件列表。 + +请求URL：`http://ip:port/mefs/listobjects` 或 `http://ip:port/ipfs/listobjects`；请求方式：GET，将列出登录账户的文件列表。 + +请求头信息：`Authorization`（"Bearer 登录验证产生的accessToken"）。 + +返回参数（JSON）：`Address`（账户以太坊钱包地址）、`Storage`（mefs或者ipfs）、`Object`（文件列表，struct）。每个文件包含：`ID`（文件序号）、`Name`（文件名）、`Size`（文件大小）、`Cid`（文件cid）、`ModTime`（文件修改时间）、`Public`（文件是否公开）、`UserDefined`（关于文件的其他一些信息，struct，包含`encryption`文件加密方式、`etag`文件ID模式默认cid）。 + +错误码： + +| HTTP状态码 | 错误码 | 错误描述 | +| --- | --- | --- | +| 401 | Authentication | Token is Null; Invalid token payload; Invalid token; | +| 516 | Storage | list object error %s | +| 518 | Storage | storage not support | + +**查询剩余空间**：请求URL：`http://ip:port/mefs/space` 或 `http://ip:port/ipfs/space`；请求方式：GET。 + +返回参数（JSON）：`Nonce`（nonce唯一值）、`Balance`（余额）、`SizeByte`（剩余空间）、`FreeByte`（免费空间）、`Expire`（过期时间）。 + +**查询剩余流量**：请求URL：`http://ip:port/mefs/traffic` 或 `http://ip:port/ipfs/traffic`；请求方式：GET。返回参数同上（`Nonce`、`Balance`、`SizeByte`、`FreeByte`、`Expire`）。 + +**空间单价查询**：可直接通过rpc调用合约接口查询空间单价，调用合约 `middleware-contracts/Proxy.sol`，调用接口`spacePrice()`，返回一个`uint64`的结果值。 + +**流量单价查询**：可直接通过rpc调用合约接口查询流量单价，调用合约 `middleware-contracts/Proxy.sol`，调用接口`trafficPrice()`，返回一个`uint64`的结果值。 + +### 购买 + +**购买空间**：请求URL：`http://ip:port/mefs/buyspace` 或 `http://ip:port/ipfs/buyspace`；请求方式：GET。请求头信息：`Authorization`。返回参数（JSON）：`tx`（交易hash）。 + +**购买流量**：请求URL：`http://ip:port/mefs/buytraffic` 或 `http://ip:port/ipfs/buytraffic`；请求方式：GET。请求头信息：`Authorization`。返回参数（JSON）：`tx`（交易hash）。 + +**申请免费空间**：用户可以向StorMark管理员发送申请，比如说发送包含指定内容的Twitter，然后管理员手动调用命令行工具给用户发放免费空间。（等管理页面实现了之后，管理员也可以通过浏览器页面给用户发放免费空间）目前命令行工具代码位于：gitlab/middleware/middleware-contracts，然后编译安装命令行工具：`go install`，使用命令行工具执行操作：`middleware-contracts admin free --type=space`，具体参数和选项看命令说明。 + +**申请免费流量**：用户可以向StorMark管理员发送申请，比如说发送包含指定内容的Twitter，然后管理员手动调用命令行工具给用户发放免费流量。（等管理页面实现了之后，管理员也可以通过浏览器页面给用户发放免费流量）目前命令行工具代码位于：gitlab/middleware/middleware-contracts，然后编译安装命令行工具：`go install`，使用命令行工具执行操作：`middleware-contracts admin free --type=traffic`，具体参数和选项看命令说明。 +# 六、FAQ（常见问题） + +**1. 什么是 Memolabs？** + +[Memolabs](https://memolabs.org/) 是一家专注于研究和扩展去中心化云存储技术应用的实验室。我们的使命是为Web3.0构建可靠的基础设施，并开发强大的去中心化存储和Web3应用工具。 + +**2. 什么是 Mefs？** + +mefs是[Memolabs](https://memolabs.org/)开发的一个低成本、可靠安全的分散式云存储系统，利用了边缘存储设备、以及区块链的不可篡改性和去中心化特性。具体信息可参考[Memolabs](https://memolabs.org/)。 + +**3. 为什么文件操作是 object？** + +在MEFS中，object和file是等价的。所以当您看到"object"或"file"时，都可以将其理解为"文件"。 + +**4. 如何设置区块链地址？** + +运行 `mefs-user/keeper/provider config Eth` 查看您所连接的区块链地址。如果想要修改，可以运行 `mefs-user/keeper/provider config Eth xxx`，其中xxx为该链的API地址。 + +**5. 如何查看 mefs 的版本？** + +运行 `mefs-user/keeper/provider version` 查看mefs的版本号。 + +**6. 如何查询我的余额？** + +在命令行中运行 `mefs-user/keeper/provider test showBalance` 查看正在运行账户的余额，单位为wei。 + +**7. 账户地址和网络地址** + +启动mefs后，会有两个地址：账户地址和网络地址；账户地址格式为0x...，网络地址格式为8M...；这两个地址实际上是等价的，一个用于与链交互，一个用于网络连接。 + +**8. 什么是 Meeda？** + +Meeda是Memolabs为以太坊Layer2，尤其是Optimistic类的Rollup推出的一种数据可用性解决方案，具有低成本、安全可靠的特点。 + +**9. 什么是数据可用性（DA）？** + +DA不仅仅包含数据的存储，还需要保证任意节点都能够访问数据。以太坊扩容方案Layer2 Rollup执行交易、提交交易之后，验证节点需要对交易数据进行验证，验证通过的交易才会被Layer1最终确定。验证过程的前提就是能够访问交易数据，因此，交易数据可以被任意节点访问，从而便于验证交易正确性的过程就叫做数据可用性。更多详情请参考：https://ethereum.org/en/developers/docs/data-availability/ + +**10. 以太坊 Layer2 如何与 Meeda 结合？** + +具体请参考 `memo-protocol/meeda/develops/connect L2 to Meeda` 和 `memo-protocol/meeda/node/Layer2+Meeda` 部分的内容（即本文档「5.9.1 How to Connect L2 to Meeda」与「5.10.1 Layer2+Meeda」章节）。 + +--- + +# 七、Community（社区） + +MEMO 是一个数据层，作为Web3基础设施，为Web3发展做出贡献。以下是我们的一些资源链接，欢迎与我们进行沟通交流。 + +**联系我们**：email：contact@memolabs.org；Memolabs 官网：https://memolabs.org/ + +**沟通交流**：twitter：https://twitter.com/MemoLabsOrg；discord：Memo Labs (https://discord.com/invite/YG4Ydv2E7X)；telegram：https://t.me/MemoLabsio；reddit：https://www.reddit.com/user/memolabs/ diff --git "a/.teamai/docs/current/\345\275\223\345\211\215\347\211\210\346\234\254.md" "b/.teamai/docs/current/\345\275\223\345\211\215\347\211\210\346\234\254.md" new file mode 100644 index 000000000..4e5f8e5dd --- /dev/null +++ "b/.teamai/docs/current/\345\275\223\345\211\215\347\211\210\346\234\254.md" @@ -0,0 +1,139 @@ +新gitbook三级目录 + +```text +1 开始了解 MEMO +├─ 1.1 欢迎与定位 +│ ├─ 1.1.1 Agent 时代的可信状态层 +│ ├─ 1.1.2 从 Data Layer 到 State Layer +├─ 1.2 产品地图 +│ ├─ 1.2.1 MEMO Protocol：协议与网络底座 +│ ├─ 1.2.2 MEMO Vault：Agent 状态存在哪里 +│ ├─ 1.2.3 MEMO Agent Gateway：谁能做什么 +│ ├─ 1.2.4 MEMO Proof：如何证明发生过 +│ ├─ 1.2.5 MEFS：去中心化存储网络 +│ ├─ 1.2.6 Data Wallet：用户身份、密钥与授权入口 +│ ├─ 1.2.7 Data Market：数据与状态资产交付 +│ └─ 1.2.8 Meeda：数据可用性与存储证明 +└─ 1.3 按角色开始 + ├─ 1.3.1 Agent / 应用开发者 + ├─ 1.3.2 Storage Provider / 节点参与者 + └─ 1.3.3 L2、企业与生态合作方 + +2 核心产品 +├─ 2.1 MEMO Protocol：协议底座持续演进 +│ ├─ 2.1.1 协议定位、网络角色与能力边界 +│ ├─ 2.1.2 原六层协议与 Agent State Layer 的映射 +│ └─ 2.1.3 Protocol 与 Vault / Gateway / Proof 的关系 +├─ 2.2 MEMO Vault：基于 MEFS 的状态存储升级 +│ ├─ 2.2.1 状态对象、命名空间与版本 +│ ├─ 2.2.2 用户持钥、加密与密钥轮换 +│ └─ 2.2.3 Local / Hosted / MEFS 存储后端 +├─ 2.3 MEMO Agent Gateway：身份与访问能力升级 +│ ├─ 2.3.1 用户身份、Agent 身份与委托关系 +│ ├─ 2.3.2 授权策略、撤销与生命周期 +│ └─ 2.3.3 MCP / REST / SDK 与签名回执 +└─ 2.4 MEMO Proof：从存储证明到 Agent 证据 + ├─ 2.4.1 访问回执与审计根锚定 + ├─ 2.4.2 MEFS / Meeda 存储证明与挑战 + └─ 2.4.3 Agent 记忆来源、运行证据与 ERC-7829 + +3 架构与状态模型 +├─ 3.1 总体架构 +│ ├─ 3.1.1 控制面、数据面与证明面 +│ ├─ 3.1.2 六层 Agent State Layer +│ └─ 3.1.3 一次 Agent 请求的完整路径 +├─ 3.2 状态模型与生命周期 +│ ├─ 3.2.1 Memory、State Object 与 Artifact +│ ├─ 3.2.2 Checkpoint、Version 与 Trace +│ └─ 3.2.3 Memory Pack、Handoff 与迁移 +└─ 3.3 信任边界 + ├─ 3.3.1 链上与链下边界 + ├─ 3.3.2 原文、密钥、承诺与证明 + └─ 3.3.3 受控处理、外部副作用与失败语义 + +4 开发者指南 +├─ 4.1 快速开始 +│ ├─ 4.1.1 第一个可持续的 Agent 任务 +│ ├─ 4.1.2 使用 SDK / REST 读写状态 +│ └─ 4.1.3 错误处理、示例与验收 +├─ 4.2 集成与适配 +│ ├─ 4.2.1 MCP 与 MEFS MCP Server +│ ├─ 4.2.2 Agent 框架与记忆引擎适配 +│ └─ 4.2.3 x402 / MEMO Facilitator 结算接入 +└─ 4.3 状态生命周期操作 + ├─ 4.3.1 保存、恢复与工作交接 + ├─ 4.3.2 团队共享与权限管理 + └─ 4.3.3 导出、撤销、删除与密钥轮换 + +5 安全、治理与运维 +├─ 5.1 用户身份、Agent 身份与策略 +│ ├─ 5.1.1 用户身份：钱包、账户 DID 与数据所有权 +│ ├─ 5.1.2 Agent 身份：Agent DID、ERC-8004 与运行主体 +│ └─ 5.1.3 用户—Agent 委托链、最小权限与撤销 +├─ 5.2 来源与核验 +│ ├─ 5.2.1 数据来源、存储完整性与版本核验 +│ ├─ 5.2.2 Agent 记忆来源、生成链路与引用校验 +│ └─ 5.2.3 Agent 运行内容、工具结果与成果验收 +└─ 5.3 Agent 运行与风险 + ├─ 5.3.1 运行轨迹、决策内容与可观测性 + ├─ 5.3.2 提示注入、记忆污染与模型漂移 + └─ 5.3.3 密钥、越权、外部副作用与故障恢复 + +6 基础设施与升级承接 +├─ 6.1 MEMO Protocol 与 MEFS +│ ├─ 6.1.1 原六层协议与网络架构 +│ ├─ 6.1.2 用户、提供者、守护者与节点 +│ └─ 6.1.3 冗余、修复、RAFI 与存储证明 +├─ 6.2 Meeda 与计算基础设施 +│ ├─ 6.2.1 Meeda / DA 总览与 Lightnode API +│ ├─ 6.2.2 FileProof、合约与 OP Stack 接入 +│ └─ 6.2.3 GRID、TEE 与受控处理 +└─ 6.3 原有产品与迁移 + ├─ 6.3.1 Data Wallet 与身份控制入口 + ├─ 6.3.2 Data Market 与选择性状态资产化 + └─ 6.3.3 DataDrive、Smart Layer 与 Storage API + +7 标准与开放集成 +├─ 7.1 标准组合 +│ ├─ 7.1.1 ERC-8004、ERC-7857 与 ERC-7829 +│ ├─ 7.1.2 MCP、A2A 与 Agent Skills +│ └─ 7.1.3 x402、支付与授权的边界 +├─ 7.2 证明与协作扩展 +│ ├─ 7.2.1 Attestation Server +│ ├─ 7.2.2 跨组织协作与受权交接 +│ └─ 7.2.3 知识、经验与训练数据授权 +└─ 7.3 兼容性与状态 + ├─ 7.3.1 协议与客户端兼容矩阵 + ├─ 7.3.2 标准成熟度与实现状态 + └─ 7.3.3 版本、弃用与迁移说明 + +8 经济模型与参考资料 +├─ 8.1 开发参考 +│ ├─ 8.1.1 API / SDK / Schema +│ ├─ 8.1.2 合约方法与事件 +│ └─ 8.1.3 网络、合约地址与环境 +├─ 8.2 服务与兼容信息 +│ ├─ 8.2.1 产品计费、存储与流量额度 +│ ├─ 8.2.2 支持的客户端、框架与后端 +│ └─ 8.2.3 术语表与能力状态索引 +└─ 8.3 Tokenomics 与治理 + ├─ 8.3.1 MEMO、质押与结算层 + ├─ 8.3.2 分配、激励与冷启动 + └─ 8.3.3 节点经济、挑战与治理 + +9 路线图、支持与社区 +├─ 9.1 路线图与设计提案 +│ ├─ 9.1.1 Phase 1：可控记忆 +│ ├─ 9.1.2 Phase 2：可携状态、轨迹与存储证明 +│ └─ 9.1.3 Phase 3：框架适配与选择性资产化 +├─ 9.2 支持与维护 +│ ├─ 9.2.1 FAQ +│ ├─ 9.2.2 排障、支持与安全反馈 +│ └─ 9.2.3 更新日志与弃用说明 +└─ 9.3 社区与历史 + ├─ 9.3.1 贡献指南与社区入口 + ├─ 9.3.2 历史文档与旧入口索引 + └─ 9.3.3 研究提案、待核实能力与决策记录 +``` + +