Insight
项目 Insight
# Aeterna 恒忆 - Insight v1.0
> 品牌名：Aeterna 恒忆
> 早期代号：Never Die
> 当前切入：宠物数字纪念 / 宠物数字殡葬
> 文档版本：1.0
> 创建日期：2026-04-12
---
## 目录
1. [项目愿景](#1-项目愿景)
2. [为什么从宠物入手](#2-为什么从宠物入手)
3. [市场分析](#3-市场分析)
4. [产品定义](#4-产品定义)
5. [技术架构](#5-技术架构)
6. [智能合约设计](#6-智能合约设计)
7. [API 设计](#7-api-设计)
8. [商业模式](#8-商业模式)
9. [竞品对比](#9-竞品对比)
10. [风险与应对](#10-风险与应对)
11. [路线图](#11-路线图)
---
## 1. 项目愿景
**让每一份陪伴，都被长久、可信地铭记。**
做一个去中心化的数字纪念与数字殡葬平台，先从宠物切入，未来逐步扩展到人类纪念场景。Aeterna 不把大文件直接塞进链上，而是把“内容证明、存储地址、版本与权限边界”做成可验证的长期档案，实现：
- 🕊️ **长期可验证保存** - 区块链确保纪念档案的存在证明、内容哈希和版本记录不可篡改；照片/视频等大文件通过去中心化存储长期保存
- 🌍 **全球访问** - 随时随地缅怀，打破地理限制
- 🔐 **隐私保护** - 加密存储 + 授权访问
- 💫 **情感传承** - 跨代际的数字纪念空间
**产品体验原则：Web2 先行，Web3 托底。** 普通用户默认用邮箱/手机号、照片上传、纪念页、家属权限和法币支付完成创建；钱包、链、hash、tokenId、txHash 等信息放在“高级详情/技术验证”里。Aeterna 的差异化不是让用户学习 Web3，而是把区块链、不可转让纪念凭证、去中心化存储和内容指纹封装成“可信、可验证、可长期保存”的纪念服务。
---
## 2. 为什么从宠物入手
| 维度 | 宠物殡葬 | 人类殡葬 |
|-----|---------|---------|
| 决策门槛 | 低（主人自主决定） | 高（需家属共识、宗教因素） |
| 监管程度 | 宽松 | 严格（民政部门监管） |
| 文化敏感度 | 较低 | 极高 |
| 试错成本 | 低 | 高 |
| 市场教育 | 容易（年轻人接受度高） | 困难 |
| 决策周期 | 短 | 长 |
| 支付意愿 | 月收入 1-2 万群体愿花 2000-5000 元 | 数万到数十万，但决策复杂 |
**核心结论：宠物是更好的 MVP 切入点**
---
## 3. 市场分析
### 3.1 宠物殡葬市场规模
**全球市场：**
- 2023 年全球宠物殡葬市场规模约 **15-20 亿美元**
- 预计 2024-2030 年 CAGR（年复合增长率）约 **6-8%**
- 北美和欧洲占据主要市场份额（约 60%）
**中国市场：**
- 2023 年中国宠物殡葬市场规模约 **10-15 亿元人民币**
- 预计 2025 年将达到 **20-25 亿元**
- 年增长率高达 **15-20%**（远高于全球平均）
- 宠物火化服务渗透率不足 10%，市场空间巨大
**背景数据：**
- 中国宠物犬猫数量 2023 年约 **1.2 亿只**
- 宠物平均寿命 10-15 年，每年约有 **800-1000 万** 宠物离世
- 宠物主人平均养宠时长 3-5 年
### 3.2 传统宠物殡葬服务与价格
| 服务类型 | 服务内容 | 价格区间（人民币） |
|---------|---------|------------------|
| 基础火化 | 单独火化 + 骨灰归还 | 500-1,500 元 |
| 标准套餐 | 火化 + 基础骨灰盒 + 接送 | 1,500-3,000 元 |
| 高端套餐 | 火化 + 精美骨灰盒 + 告别仪式 + 纪念品 | 3,000-8,000 元 |
| 豪华定制 | 全套服务 + 墓地/灵位 + 定制纪念 | 8,000-30,000+ 元 |
| 集体火化 | 多宠物集体处理 | 200-500 元 |
**延伸服务：**
- 宠物墓地/灵位：5,000-50,000 元/年
- 骨灰钻石/饰品：3,000-20,000 元
- 纪念视频/相册：500-3,000 元
- 法事/超度仪式：1,000-5,000 元
### 3.3 目标用户画像
**年龄分布（中国）：**
| 年龄段 | 占比 | 特征 |
|-------|------|------|
| 18-25 岁 | 25% | Z 世代，学生/初入职场，情感依赖强 |
| 26-35 岁 | 45% | 主力消费群，收入稳定，支付意愿高 |
| 36-45 岁 | 20% | 家庭养宠，重视仪式感 |
| 46 岁 + | 10% | 空巢老人，情感寄托 |
**收入水平：**
- 月收入 1 万以下：30%
- 月收入 1-2 万：40%
- 月收入 2-5 万：25%
- 月收入 5 万 +：5%
**地域分布：**
- 一线城市（北上广深）：35%
- 新一线城市：30%
- 二线城市：20%
- 其他：15%
**支付意愿（宠物身后事）：**
- 愿意花费 500 元以下：25%
- 500-2000 元：40%
- 2000-5000 元：25%
- 5000 元以上：10%
**关键发现：**
- **年轻群体（26-35 岁）支付意愿最强**
- 一线城市接受度显著高于其他城市
- 女性宠物主人更愿意为纪念服务付费
### 3.4 对 Web3 技术的接受度
| 群体 | NFT 认知度 | 愿意尝试 | 主要顾虑 |
|-----|-----------|---------|---------|
| 18-25 岁 | 60% | 40% | 价格波动、安全性 |
| 26-35 岁 | 50% | 35% | 实用性、长期价值 |
| 36-45 岁 | 30% | 15% | 技术门槛、信任 |
| 46 岁 + | 10% | 5% | 完全不了解 |
**接受度洞察：**
- Web3 原生用户对 NFT 纪念接受度高
- 大众用户更关注**功能价值**而非技术本身
- "上链"概念需要转化为用户可理解的价值主张
- 产品默认不要求用户连接钱包、选择链或理解 hash；这些能力作为高级选项服务 Web3 用户和验证场景
### 3.5 竞品分析
**现有宠物纪念平台：**
| 平台 | 类型 | 主要功能 | 状态 |
|-----|------|---------|------|
| **FurEver** (foreverfur.com) | 纪念平台 | 数字纪念馆、照片墙、故事分享 | 运营中 |
| **Lap of Love** | 服务预约 | 临终关怀 + 纪念页面 | 美国领先 |
| **Rainbows Bridge** | 社区 | 宠物悼念社区、诗歌、故事 | 运营 20+ 年 |
| **宠物天堂** | 纪念网站 | 数字灵位、祭奠 | 运营中 |
| **萌宠星球** | APP | 纪念空间、社区 | 运营中 |
**区块链结合项目：**
| 项目 | 类型 | 区块链 | 状态 |
|-----|------|--------|------|
| **Pet3** | NFT + 纪念 | Ethereum | 已停止 |
| **CryptoPets Memorial** | 纪念 NFT | BSC | 活跃度低 |
| **Pawtocol** | 宠物服务 | Polygon | 转型中 |
**现状分析：**
- 目前**尚未出现大规模成熟的宠物纪念类区块链项目**
- 早期尝试多聚焦于 NFT 宠物游戏/收藏，而非纪念
- 多数项目因 NFT 市场遇冷而停滞
- **这是一个市场空白点**
### 3.6 成功与失败案例
**成功案例：Lap of Love（美国）**
- **模式**：上门安乐死 + 火化 + 数字纪念
- **成功因素**：
- 解决宠物最后时刻的痛苦问题
- 服务标准化、专业化
- 兽医网络覆盖全美
- **估值**：数千万美元级别
**失败案例：Pet3（区块链项目）**
- **模式**：宠物 NFT + 纪念上链
- **失败原因**：
- NFT 市场整体遇冷
- 产品体验差，区块链概念大于实用
- 缺乏真实需求支撑
- 代币经济模型不可持续
**关键洞察：**
1. **成功 = 情感价值 + 便捷服务**，而非技术堆砌
2. 区块链必须解决实际问题（如长期可验证存证、所有权/创建证明）
3. 纯概念性 Web3 项目难以持续
---
## 4. 产品定义
### 4.1 数据分层架构
```
┌─────────────────────────────────────────────────────────┐
│ 用户可见层（前端） │
├─────────────────────────────────────────────────────────┤
│ 📋 宠物基本信息 │ 名字、品种、生日、离世日期、照片 │
│ 📖 宠物故事 │ 主人写的回忆录、成长故事 │
│ 🖼️ 照片/视频墙 │ 生活点滴、珍贵瞬间 │
│ 🕯️ 祭奠区 │ 献花、点灯、留言（其他用户可访问） │
│ 📜 纪念证书 │ 默认展示为可信纪念凭证；高级详情可验证 SBT │
│ 🔐 私密空间 │ 仅授权家属可见的加密内容 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 存储层 │
├─────────────────────────────────────────────────────────┤
│ 链上（默认 Base，可选 Mantle/Arbitrum/Polygon） │ 链下（Arweave/IPFS） │
│ ✓ 纪念证书 NFT/SBT │ ✓ 高清照片/视频（加密） │
│ ✓ Manifest 哈希 │ ✓ 宠物故事详情 │
│ ✓ 时间戳/版本号 │ ✓ 私密内容 │
│ ✓ 所有权/创建证明 │ ✓ 祭奠留言 │
│ ✓ 内容包存储 URI │ ✓ 音频（如宠物叫声保存） │
└─────────────────────────────────────────────────────────┘
```
### 4.2 上链数据明细
**原则：宠物生平、照片、小视频可以进入“链上可验证纪念档案”，但文件本体不直接写入合约存储。**
推荐将照片/视频/音频/故事组织成一个 `memorial manifest`：
- 明文公开内容：可公开的名字、故事摘要、封面图等
- 私密内容：加密后的照片、视频、音频、长故事、家属留言
- 文件索引：每个媒体文件的 hash、大小、类型、存储 URI、加密方式
- 版本信息：manifest 版本、创建时间、更新记录
链上只保存 `manifestHash`、`manifestURI`、`schemaVersion`、`createdAt`、`owner/creator` 等证明信息。这样仍然能实现“逝者信息进入链上纪念档案”，同时避免把大文件、隐私内容和错误内容永久裸露在公链上。
| 数据类型 | 存储位置 | 是否公开 | 说明 |
|---------|---------|---------|------|
| 纪念证书 NFT/SBT | 链上 | 公开 | 不可转让，包含唯一 ID、manifestHash、创建时间，可选公开昵称 |
| Manifest 哈希 | 链上 | 公开 | 验证链下纪念档案完整性 |
| Manifest URI | 链上 | 公开 | 指向 Arweave/IPFS 上的纪念档案索引；私密字段必须加密 |
| 照片/视频/音频 | Arweave/IPFS + 加密 | 授权可见 | 原文件不直接上链，链上只存 hash 和索引 |
| 宠物故事 | Manifest + 去中心化存储 | 公开/私密可选 | 公开内容可明文，私密内容加密 |
| 祭奠留言 | 数据库/IPFS，定期摘要上链 | 公开 | 高频内容不上链，必要时将 Merkle Root 上链存证 |
| 家属列表 | 数据库/KMS | 私密 | 不建议放公链；链上地址授权会暴露关系图谱 |
### 4.3 用户旅程
```
1️⃣ 创建纪念空间
┌──────────────┐
│ 访问网站/APP │ → 邮箱/手机号登录；钱包作为高级选项
└──────────────┘
↓
┌──────────────┐
│ 填写宠物信息 │ → 名字、照片、生日、离世日期、故事
└──────────────┘
↓
┌──────────────┐
│ 支付服务费 │ → 法币支付（平台代付 Gas）；海外版可选加密货币
└──────────────┘
↓
┌──────────────┐
│ 生成纪念凭证 │ → 平台后端代铸；高级用户可查看链上证明
└──────────────┘
2️⃣ 访问纪念空间
┌──────────────┐
│ 输入纪念链接 │ → 任何人都可访问公开部分
└──────────────┘
↓
┌──────────────┐
│ 浏览宠物信息 │ → 照片墙、故事、时间线
└──────────────┘
↓
┌──────────────┐
│ 祭奠互动 │ → 献花、点灯、留言（默认免费/法币付费，不引入代币）
└──────────────┘
3️⃣ 家属授权管理
┌──────────────┐
│ 邀请家属 │ → 生成邀请链接/码
└──────────────┘
↓
┌──────────────┐
│ 授权访问 │ → 家属获得私密内容访问权
└──────────────┘
```
### 4.4 隐私保护方案
**上链 ≠ 公开**，关键看架构设计：
| 方案 | 说明 | 优缺点 |
|------|------|--------|
| **私有链/联盟链** | 只有授权节点能访问 | ✅ 隐私好<br>❌ 失去去中心化意义 |
| **公有链 + 数据加密** | 数据加密后上链，只有授权人能解密 | ✅ 平衡隐私与去中心化<br>⚠️ 密钥管理复杂 |
| **混合架构** | 链上只存哈希/索引，敏感数据链下存储 | ✅ 最实用<br>✅ 成本最低 |
**推荐方案（混合架构）：**
```
链上存储：
- 数据哈希（用于验证完整性）
- Manifest URI
- 版本号和时间戳
- 所有权/创建证明
- 不可转让纪念凭证
链下存储（加密）：
- 逝者详细信息
- 照片/视频
- 家属信息
- 祭奠记录
```
**隐私保护技术：**
- **对称加密** + **非对称加密** 结合
- 家属通过钱包签名获取解密密钥
- 密钥采用 envelope encryption：每份内容一个数据密钥，数据密钥再分别用授权成员公钥或平台 KMS 包装
- 需要设计密钥恢复/继承机制：用户丢钱包、换手机号、家属继承、平台停止服务时仍能恢复授权
- 零知识证明、机密计算不作为 MVP 必选项，只在后续需要“证明有权限但不暴露身份”时再评估
**重要边界：**
- 公链不是私密数据库。上链意味着公开可验证，隐私必须依赖加密和密钥管理。
- IPFS 不是自动永久存储。内容需要 pinning、多节点备份，或使用 Arweave 等更适合长期保存的存储层。
- “删除”在链上只能表现为撤销、隐藏或新版本覆盖，不能真正抹除已公开上链的数据。因此敏感内容默认不上明文链。
---
## 5. 技术架构
### 5.1 技术选型
| 层级 | 技术选择 | 理由 |
|-----|---------|------|
| **区块链** | Base 默认 + Mantle/Arbitrum/Polygon 可选 + Ethereum 摘要锚定 | 保持 EVM 兼容，默认低成本铸造；高级场景可多链备份或以太坊最终证明 |
| **存储** | Arweave + IPFS/Pinata | Arweave 保存核心纪念档案和关键媒体，IPFS/Pinata 做访问加速和低成本分发 |
| **前端** | Next.js 14 + Tailwind | SSR 利于 SEO、开发效率高 |
| **后端** | Next.js API / Node.js | MVP 可先用 Next.js 全栈，复杂后端服务后置 |
| **数据库** | PostgreSQL | 保存用户、索引、草稿、支付、权限；Redis 可后置 |
| **钱包** | RainbowKit / 托管钱包 | Web3 用户可连接钱包，大众用户可用邮箱注册 + 平台代铸 |
| **合约** | Solidity + Hardhat | 标准工具链，优先实现最小纪念凭证合约 |
### 5.2 总体架构图
```
┌─────────────────────────────────────────────────────────────────────┐
│ 前端层 (Next.js) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 创建纪念 │ │ 纪念展厅 │ │ 祭奠互动 │ │ 家属管理 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────┐
│ API 层 (Node.js) │
│ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │
│ │ POST /memorial │ │ GET /memorial/:id│ │ POST /tribute │ │
│ │ 创建纪念 │ │ 获取纪念信息 │ │ 提交祭奠 │ │
│ └──────────────────┘ └──────────────────┘ └──────────────────┘ │
│ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │
│ │ POST /upload │ │ POST /invite │ │ GET /family │ │
│ │ 上传媒体文件 │ │ 邀请家属 │ │ 获取家属列表 │ │
│ └──────────────────┘ └──────────────────┘ └──────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
↓
┌───────────────────────────┼───────────────────────────┐
↓ ↓ ↓
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 区块链层 │ │ 存储层 │ │ 数据库层 │
│ Base/Mantle │ │ Arweave/IPFS │ │ PostgreSQL │
│ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │
│ │SBT 合约 │ │ │ │媒体文件 │ │ │ │用户信息 │ │
│ │存证索引 │ │ │ │加密数据 │ │ │ │权限/密钥│ │
│ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │
│ │ │ Arweave+Pinata│ │ 任务状态机 │
└───────────────┘ └───────────────┘ └───────────────┘
```
### 5.3 推荐数据流
```
1. 用户创建纪念草稿
- 数据先进入数据库，状态为 draft
2. 用户上传照片/视频/音频
- 前端或后端生成文件 hash
- 私密文件先加密，再上传 Arweave/IPFS
- 数据库记录 upload 状态，避免上传成功但链上失败后无法追踪
3. 生成 memorial manifest
- manifest 记录宠物生平、媒体索引、权限策略、schemaVersion
- manifest 可分为 public manifest 和 encrypted private manifest
4. 链上铸造不可转让纪念凭证
- 合约只写入 memorialId、manifestHash、manifestURI、createdAt、schemaVersion
- 不写入大视频、长故事、家属邮箱、私密姓名等敏感内容
- 默认铸造到 Base；高级用户可选择 Mantle/Arbitrum/Polygon，多链结果作为 deployments 保存
5. 发布纪念页
- 前端从数据库和去中心化存储读取内容
- 验证页面可对比链上 hash 与 manifest hash，证明内容未被篡改
```
### 5.4 状态机与一致性
创建流程涉及数据库、去中心化存储、链上交易、支付系统，必须避免“双写不一致”：
```
draft → uploading → uploaded → manifest_created → minting → minted → indexed → published
↓ ↓
failed retryable_failed
```
关键要求：
- 每一步都要可重试，尤其是上传成功但交易失败、交易成功但数据库未更新的场景。
- 以后端任务队列或 outbox 记录链上交易状态，不依赖前端页面停留。
- 所有链上事件需要 indexer 同步回数据库，纪念页读取数据库索引，验证页读取链上数据。
### 5.5 Gas Fee 处理方案
```
方案：平台代付（Gasless）
用户 → 支付法币给平台（海外版可选加密货币）
↓
平台 → 使用元交易（Meta Transaction）或平台代铸代付 Gas
↓
用户无感知，体验同 Web2 产品
技术实现：
- Biconomy / Gelato 等 Gasless 服务
- 或自建中继器（Relayer）
```
**备选方案：**
- 默认主网用 **Base**（低成本、EVM 兼容、消费级入口更强）
- 亚洲/低费扩展可选 **Mantle**；成熟生态扩展可选 **Arbitrum**；兼容老 NFT 生态可选 **Polygon**
- 关键纪念凭证可定期将摘要锚定到 **Ethereum Mainnet**，作为更强的长期证明
- 国内版优先使用法币支付 + 平台代铸；海外/Web3 版再开放用户自持钱包
- 暂不引入代币支付和链上道具消费，避免合规和投机风险
### 5.6 多链部署策略
**原则：多链能力，单链默认。**
普通用户不需要选择链，产品默认生成“链上纪念凭证”；高级用户才看到链选择。
| 链 | 定位 | 使用建议 |
|----|------|---------|
| **Base** | 默认主链 | 低成本、EVM 兼容、Coinbase 生态和消费级入口更强 |
| **Mantle** | 亚洲/低费扩展 | 适合低成本大量铸造，MNT 生态对亚洲 Web3 用户更友好 |
| **Arbitrum** | 成熟 L2 备选 | 生态成熟、稳定，适合严肃链上凭证项目 |
| **Polygon** | 兼容老 NFT 生态 | 成本低、历史 NFT 生态强，可作为备选部署链 |
| **Ethereum Mainnet** | 最终锚定 | 不建议每份档案都直接铸造，可用于高端套餐或周期性 Merkle Root 摘要锚定 |
**数据模型建议：**
```
memorial
├── memorialId
├── manifestHash
├── manifestURI
└── deployments[]
├── chainId
├── chainName
├── contractAddress
├── tokenId
├── txHash
└── status
```
**用户感知：**
- 普通用户：默认链由平台选择，界面只显示“链上纪念凭证已生成”。
- Web3/高级用户：可在高级设置中选择 Base、Mantle、Arbitrum 或 Polygon。
- 高端长期保存：可选择 Ethereum 摘要锚定，但不把所有媒体直接写入 Ethereum。
**风险控制：**
- 多链会增加合约地址、RPC、区块浏览器、indexer、失败重试和版本管理复杂度。
- 产品默认只开放一条主链，避免用户被链选择打断。
- 每个档案需要明确 primary deployment，其他链作为备份/扩展/锚定。
---
## 6. 智能合约设计
### 6.1 纪念 NFT/SBT 合约
**设计原则：**
- 纪念凭证默认不可转让，避免逝者纪念被交易化、投机化。
- 合约只保存最小证明字段：`memorialId`、`manifestHash`、`manifestURI`、`schemaVersion`、`createdAt`。
- 宠物名字、生日、离世日期、品种等可以放在 public manifest；如果未来扩展到人类殡葬，应默认加密，不直接明文上链。
- 如需更新内容，采用版本化 manifest：旧版本不删除，新版本写入新的 hash，并在前端展示当前版本。
> 下方代码是 v1.0 推荐方向：最小不可转让纪念凭证，只保存 manifest 证明信息。
```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
contract PetMemorialSBT is ERC721, ERC721URIStorage, Ownable {
struct MemorialRecord {
bytes32 manifestHash; // hash of public/encrypted memorial manifest
string manifestURI; // arweave/ipfs URI of the manifest
uint64 createdAt;
uint32 schemaVersion;
bool exists;
}
mapping(uint256 => MemorialRecord) public memorials;
mapping(address => uint256[]) public userMemorials;
uint256 private _nextTokenId = 1;
event MemorialCreated(
uint256 indexed tokenId,
address indexed owner,
bytes32 manifestHash,
string manifestURI,
uint32 schemaVersion
);
error Soulbound();
constructor() ERC721("Aeterna Pets Memorial", "AETPET") Ownable(msg.sender) {}
function createMemorial(
address to,
bytes32 manifestHash,
string calldata manifestURI,
uint32 schemaVersion
) external returns (uint256 tokenId) {
tokenId = _nextTokenId++;
memorials[tokenId] = MemorialRecord({
manifestHash: manifestHash,
manifestURI: manifestURI,
createdAt: uint64(block.timestamp),
schemaVersion: schemaVersion,
exists: true
});
_safeMint(to, tokenId);
_setTokenURI(tokenId, manifestURI);
userMemorials[to].push(tokenId);
emit MemorialCreated(tokenId, to, manifestHash, manifestURI, schemaVersion);
}
function getMemorial(uint256 tokenId) external view returns (MemorialRecord memory) {
require(memorials[tokenId].exists, "Memorial does not exist");
return memorials[tokenId];
}
function getUserMemorials(address user) external view returns (uint256[] memory) {
return userMemorials[user];
}
function _update(
address to,
uint256 tokenId,
address auth
) internal override returns (address) {
address from = _ownerOf(tokenId);
if (from != address(0) && to != address(0)) {
revert Soulbound();
}
return super._update(to, tokenId, auth);
}
function tokenURI(uint256 tokenId) public view override(ERC721, ERC721URIStorage) returns (string memory) {
return super.tokenURI(tokenId);
}
function supportsInterface(bytes4 interfaceId) public view override(ERC721, ERC721URIStorage) returns (bool) {
return super.supportsInterface(interfaceId);
}
}
```
### 6.2 访问控制合约
**风险提示：** 公链访问控制只能表达“某地址被授权”，不能真正保证私密内容不被转发，也会暴露地址之间的关系。MVP 阶段建议将家属权限、邮箱、邀请状态、密钥包装记录放在数据库/KMS；链上只在必要时写入不可反推的授权承诺或审计事件。
```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/access/Ownable.sol";
contract MemorialAccessControl is Ownable {
// memorialId => (user => isAuthorized)
mapping(uint256 => mapping(address => bool)) public authorized;
// memorialId => owner
mapping(uint256 => address) public memorialOwners;
event AccessGranted(uint256 indexed memorialId, address indexed user);
event AccessRevoked(uint256 indexed memorialId, address indexed user);
constructor() Ownable(msg.sender) {}
function setMemorialOwner(uint256 memorialId, address owner) external onlyOwner {
memorialOwners[memorialId] = owner;
}
function grantAccess(uint256 memorialId, address user) external {
require(msg.sender == memorialOwners[memorialId] || msg.sender == owner(), "Not authorized");
authorized[memorialId][user] = true;
emit AccessGranted(memorialId, user);
}
function revokeAccess(uint256 memorialId, address user) external {
require(msg.sender == memorialOwners[memorialId] || msg.sender == owner(), "Not authorized");
authorized[memorialId][user] = false;
emit AccessRevoked(memorialId, user);
}
function isAuthorized(uint256 memorialId, address user) external view returns (bool) {
// Owner is always authorized
if (user == memorialOwners[memorialId] || user == owner()) {
return true;
}
return authorized[memorialId][user];
}
function batchGrantAccess(uint256 memorialId, address[] calldata users) external {
require(msg.sender == memorialOwners[memorialId] || msg.sender == owner(), "Not authorized");
for (uint256 i = 0; i < users.length; i++) {
authorized[memorialId][users[i]] = true;
emit AccessGranted(memorialId, users[i]);
}
}
}
```
### 6.3 祭奠互动合约（后置）
祭奠互动属于高频、低金额、需要审核的内容，不建议 MVP 直接上链。推荐先放数据库，必要时每天或每周将留言集合的 Merkle Root 上链，证明平台没有事后篡改。链上献花/蜡烛可以作为海外 Web3 版的后续玩法，不作为核心差异化。
```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/access/Ownable.sol";
contract Tribute is Ownable {
struct Flower {
address from;
uint256 timestamp;
string flowerType;
string message;
}
struct TributeStats {
uint256 totalFlowers;
uint256 totalCandles;
uint256 totalMessages;
}
// memorialId => flowers
mapping(uint256 => Flower[]) public memorialFlowers;
// memorialId => stats
mapping(uint256 => TributeStats) public stats;
// Flower types and their prices (in wei)
mapping(string => uint256) public flowerPrices;
event FlowerSent(
uint256 indexed memorialId,
address indexed from,
string flowerType,
string message
);
constructor() Ownable(msg.sender) {
// Set default flower prices
flowerPrices["rose"] = 0.001 ether;
flowerPrices["lily"] = 0.002 ether;
flowerPrices["chrysanthemum"] = 0.001 ether;
flowerPrices["free"] = 0;
}
function sendFlower(
uint256 memorialId,
string calldata flowerType,
string calldata message
) external payable {
uint256 price = flowerPrices[flowerType];
require(msg.value >= price, "Insufficient payment");
memorialFlowers[memorialId].push(Flower({
from: msg.sender,
timestamp: block.timestamp,
flowerType: flowerType,
message: message
}));
stats[memorialId].totalFlowers++;
emit FlowerSent(memorialId, msg.sender, flowerType, message);
}
function getFlowers(uint256 memorialId, uint256 limit, uint256 offset)
external view returns (Flower[] memory)
{
Flower[] memory allFlowers = memorialFlowers[memorialId];
uint256 length = allFlowers.length;
if (offset >= length) {
return new Flower[](0);
}
uint256 end = offset + limit;
if (end > length) {
end = length;
}
uint256 resultLength = end - offset;
Flower[] memory result = new Flower[](resultLength);
for (uint256 i = 0; i < resultLength; i++) {
result[i] = allFlowers[offset + i];
}
return result;
}
function withdraw() external onlyOwner {
payable(owner()).transfer(address(this).balance);
}
receive() external payable {}
fallback() external payable {}
}
```
---
## 7. API 设计
### 7.1 创建纪念（POST）
**请求：**
```http
POST /api/memorial/create
Content-Type: application/json
Authorization: Bearer <token>
{
"name": "小白",
"species": "dog",
"breed": "萨摩耶",
"birthDate": "2015-03-15",
"passedDate": "2024-01-10",
"story": "小白陪伴了我们 9 年...",
"photos": ["ipfs://...", "ipfs://..."],
"isPrivate": false
}
```
**后端处理流程：**
```
1. 验证用户身份（钱包签名/JWT）
2. 上传元数据到 IPFS → 获得 metadataUri: "ipfs://QmXxx..."
3. 调用智能合约 createMemorial() → 获得 tokenId: 12345
4. 保存记录到数据库
5. 返回结果
```
**响应：**
```json
{
"success": true,
"data": {
"tokenId": 12345,
"txHash": "0xabc...",
"memorialUrl": "/memorial/12345",
"metadataUri": "ipfs://QmXxx..."
}
}
```
### 7.2 查询纪念（GET）
**请求：**
```http
GET /api/memorial/:tokenId
Authorization: Bearer <token>
```
**后端处理流程：**
```
1. 从数据库获取缓存的纪念信息
2. 验证用户是否有私密内容访问权限
3. 从 IPFS 获取元数据
4. 返回完整信息
```
**响应：**
```json
{
"success": true,
"data": {
"tokenId": 12345,
"name": "小白",
"species": "dog",
"breed": "萨摩耶",
"birthDate": "2015-03-15",
"passedDate": "2024-01-10",
"story": "小白陪伴了我们 9 年...",
"photos": ["https://gateway.pinata.cloud/ipfs/..."],
"tributes": [],
"owner": "0x123...",
"isPrivate": false,
"createdAt": "2024-01-15T10:00:00Z"
}
}
```
### 7.3 提交祭奠（POST）
**请求：**
```http
POST /api/tribute/send
Content-Type: application/json
{
"tokenId": 12345,
"type": "flower",
"flowerType": "rose",
"message": "愿你在汪星球快乐..."
}
```
**后端处理流程：**
```
1. 验证请求
2. 记录到数据库（高频数据不上链，降低成本）
3. 可选：调用合约 sendFlower()（付费用户）
4. 返回成功
```
**响应：**
```json
{
"success": true,
"data": {
"tributeId": "67890",
"txHash": "0xdef...",
"message": "祭奠已提交"
}
}
```
### 7.4 上传媒体文件（POST）
**请求：**
```http
POST /api/upload
Content-Type: multipart/form-data
file: <image/video file>
type: "photo" | "video" | "audio"
```
**响应：**
```json
{
"success": true,
"data": {
"ipfsHash": "QmXxx...",
"ipfsUrl": "ipfs://QmXxx...",
"gatewayUrl": "https://gateway.pinata.cloud/ipfs/QmXxx...",
"fileType": "image/jpeg",
"fileSize": 1024000
}
}
```
### 7.5 邀请家属（POST）
**请求：**
```http
POST /api/invite
Content-Type: application/json
Authorization: Bearer <token>
{
"tokenId": 12345,
"email": "family@example.com",
"role": "editor" | "viewer"
}
```
**响应：**
```json
{
"success": true,
"data": {
"inviteId": "inv_123",
"inviteLink": "https://neverdie.app/invite/inv_123",
"expiresAt": "2024-01-20T10:00:00Z"
}
}
```
### 7.6 获取家属列表（GET）
**请求：**
```http
GET /api/memorial/:tokenId/family
Authorization: Bearer <token>
```
**响应：**
```json
{
"success": true,
"data": {
"owner": {
"address": "0x123...",
"email": "owner@example.com"
},
"members": [
{
"address": "0x456...",
"email": "family@example.com",
"role": "editor",
"grantedAt": "2024-01-15T10:00:00Z"
}
]
}
}
```
---
## 8. 商业模式
### 8.1 分层定价策略
| 套餐 | 价格 | 包含内容 | 目标用户 |
|-----|------|---------|---------|
| **免费版** | ¥0 | 基础纪念页面、少量照片、公开访问、无长期存储承诺 | 价格敏感用户（引流） |
| **基础版** | ¥199 | 500MB 存储、不可转让纪念证书、私密空间、5 位家属授权 | 主流用户 |
| **高级版** | ¥499 | 5GB 存储、核心内容 Arweave 长期保存、定制模板、优先客服、无限家属 | 高支付意愿用户 |
| **尊享版** | ¥1,999 | 定制长期保存包、AI 修复老照片、实体纪念册、专属顾问 | 高端用户 |
**定价边界：**
- “永久/长期保存”有真实存储成本，不建议放在免费版承诺中。
- “无限存储”容易形成成本黑洞，建议改为“定制长期保存包”或设置合理容量。
- 国内版使用“数字纪念证书/可信存证”表述；海外/Web3 版可使用 NFT/SBT 表述。
### 8.2 持续收入来源
| 收入类型 | 说明 | 预估占比 |
|---------|------|---------|
| 套餐订阅 | 年费制（如 ¥99/年） | 40% |
| 增值服务 | 额外存储、实体周边（骨灰盒、相框） | 30% |
| 祭奠道具 | 虚拟鲜花、蜡烛（¥1-10/个，默认法币支付，不引入代币） | 15% |
| B2B 合作 | 宠物医院/殡葬服务分成 | 15% |
### 8.3 商业化路径
```
第一阶段：工具产品（0-6 个月）
├── 免费/低价创建纪念空间
├── 验证核心需求
└── 积累种子用户
第二阶段：平台生态（6-18 个月）
├── 订阅制服务
├── 祭奠道具虚拟物品
├── 宠物医院合作入驻
└── 开始盈利
第三阶段：产业整合（18 个月+）
├── 与传统宠物殡葬合作
├── 实体 + 数字双模式
├── 保险/信托合作（预付服务费）
└── 扩展至人类殡葬
```
---
## 9. 竞品对比
### 9.1 与传统宠物殡葬对比
| 维度 | 传统宠物殡葬 | 数字宠物殡葬（本项目） |
|-----|-------------|---------------------|
| **价格** | 500-30,000+ 元 | 0-1,999 元 |
| **长期保存** | 骨灰盒/墓地（需维护） | 链上存证 + 去中心化存储 + 可导出备份 |
| **地理限制** | 需到指定地点祭拜 | 随时随地访问 |
| **信息容量** | 墓碑刻字有限 | 可扩展照片、视频、故事容量 |
| **分享性** | 无法分享 | 链接分享全球访问 |
| **互动性** | 线下祭拜 | 在线献花、留言、点灯 |
| **传承性** | 代际传承困难 | 可继承、可授权管理，不作为交易资产流通 |
| **仪式感** | 实体告别仪式 | 数字仪式 + 可定制实体周边 |
| **环保** | 火化有碳排放 | 低碳/零碳 |
| **信任** | 服务不透明 | 链上可验证 |
### 9.2 优缺点总结
**传统优势：**
- 实体寄托（骨灰、墓地）
- 仪式感更强
- 中老年群体接受度高
**数字优势：**
- 成本低 10 倍以上
- 长期保存、可验证、难以篡改
- 全球化访问
- 丰富的多媒体内容
- 易于分享和传承
**最佳方案：线上线下结合**
- 数字纪念为主
- 可选实体周边（骨灰盒、纪念册）
- 与线下殡葬服务商合作分成
---
## 10. 风险与应对
| 风险 | 严重程度 | 应对策略 |
|-----|---------|---------|
| **市场教育成本高** | 高 | 淡化 Web3 概念，强调功能价值 |
| **需求频次低** | 高 | 扩展至生前记录、健康管理 |
| **NFT 市场遇冷** | 中 | 不依赖投机，聚焦实用价值 |
| **监管不确定性** | 中 | 合规设计，避免金融化 |
| **竞争加剧** | 中 | 快速建立品牌和用户网络 |
| **技术门槛** | 低 | 抽象化区块链，用户体验优先 |
| **情感敏感性** | 中 | 产品设计需极度谨慎和尊重 |
| **数据隐私** | 中 | 加密存储、最小化上链数据 |
| **长期运营** | 中 | 去中心化存储 + 可导出备份 + 运营托管承诺 |
| **“永久保存”承诺过强** | 高 | 明确链上保存的是证明和索引，媒体文件采用 Arweave/IPFS 多备份，并提供用户导出包 |
| **视频直接上链成本过高** | 高 | 视频原文件加密后放去中心化存储，链上只保存 hash、URI 和版本信息 |
| **公链隐私误判** | 高 | 家属关系、邮箱、私密故事不上明文链；采用加密、KMS、最小化上链字段 |
| **密钥丢失导致内容不可访问** | 高 | 设计密钥恢复、家属继承、备份密钥和平台托管选项 |
| **NFT 可交易引发情感/合规风险** | 高 | 纪念凭证默认不可转让，国内版避免 NFT/Token/炒作话术 |
| **多系统状态不一致** | 中 | 引入创建状态机、任务队列、链上事件 indexer 和失败重试机制 |
| **多链复杂度上升** | 中 | 默认 Base 单链，Mantle/Arbitrum/Polygon 放在高级设置；每个档案记录 primary deployment |
### 架构优化结论
1. **链上负责证明，不负责承载大文件**：链上保存 Memorial ID、manifestHash、时间戳、版本和不可转让纪念凭证；照片、视频、音频通过加密去中心化存储保存。
2. **NFT 是纪念凭证，不是交易资产**：默认采用不可转让 NFT/SBT，强调纪念、验证、继承，不强调交易和投资。
3. **私密性来自加密和密钥管理**：公链只提供公开可验证能力，不能天然提供隐私。
4. **长期保存需要存储策略**：IPFS 需要 pinning，Arweave 可用于核心内容长期保存，平台还应提供导出包。
5. **国内外版本要分层**：国内版强调“可信存证/数字纪念证书/长期保存”，海外版再开放钱包、NFT/SBT 和加密货币选项。
6. **多链能力，单链默认**：默认 Base，Mantle/Arbitrum/Polygon 作为高级选项，Ethereum 只做最终摘要锚定。
### 关键成功因素
1. **情感第一，技术第二**：用户为情感价值付费，不为区块链付费
2. **极简用户体验**：无需理解钱包、Gas 费等概念
3. **可持续商业模式**：避免依赖代币投机
4. **信任建立**：透明运营、隐私保护、长期承诺
5. **社区驱动**：宠物主人的情感共鸣和互助
---
## 11. 路线图
### 11.1 MVP 开发（第 1-2 周）
```
Week 1-2: MVP 开发
├── 智能合约开发与测试
│ ├── PetMemorialSBT.sol
│ ├── 不可转让纪念凭证/SBT 逻辑
│ └── 部署到 Base Sepolia 测试网（保留 Mantle/Arbitrum/Polygon 配置）
├── 基础前端页面
│ ├── 创建纪念页面
│ ├── 纪念展示页面
│ └── 验证页面（对比链上 hash 与 manifest）
└── 去中心化存储集成
├── Arweave/IPFS 上传
├── 加密媒体文件
└── memorial manifest 生成
```
### 11.2 功能完善（第 3-4 周）
```
Week 3-4: 功能完善
├── 祭奠互动功能
│ ├── 献花、点灯
│ └── 留言系统（默认链下存储，后续摘要上链）
├── 家属授权系统
│ ├── 邀请链接生成
│ ├── 权限管理
│ └── 密钥恢复/继承方案
└── 支付集成
├── 法币支付（Stripe/支付宝）
└── 平台代铸/代付 Gas
```
### 11.3 测试与上线（第 5-6 周）
```
Week 5-6: 测试与上线
├── 内部测试
│ ├── 功能测试
│ ├── 安全审计
│ └── 性能优化
├── 种子用户招募
│ ├── 宠物社群推广
│ └── 内测反馈收集
└── 正式上线
├── Base 主网部署
└── 官网发布
```
**MVP 暂不做：**
- 视频原文件直接写入合约
- 可交易 NFT
- 代币、DAO、链上祭奠道具
- 让普通用户选择链
- 复杂零知识证明/机密计算
- 人类殡葬扩展
### 11.4 增长阶段（第 7-8 周）
```
Week 7-8: 增长
├── 宠物医院合作
│ ├── B2B 方案准备
│ └── 首批合作伙伴签约
├── 社交媒体营销
│ ├── 小红书/抖音内容运营
│ └── KOL 合作
└── 用户反馈迭代
├── 功能优化
└── 用户体验改进
```
### 11.5 长期规划（6-18 个月）
```
Phase 2 (6-12 个月):
├── 移动端 APP 开发
├── AI 功能（照片修复、AI 生成纪念视频）
├── 社区功能（宠物主人互助小组）
└── 实体周边商城
Phase 3 (12-18 个月):
├── 人类殡葬服务探索
├── 跨国扩张
├── 长期托管基金/数据托管承诺
└── 与保险公司合作（预付服务）
```
---
## 附录
### A. 关键指标（KPIs）
| 指标 | 目标（6 个月） | 目标（12 个月） |
|-----|--------------|---------------|
| 注册用户 | 10,000 | 50,000 |
| 创建纪念数 | 5,000 | 25,000 |
| 付费转化率 | 5% | 10% |
| 月收入 | ¥100,000 | ¥500,000 |
| NPS | 50+ | 70+ |
### B. 技术资源
- **Base 文档**: https://docs.base.org/
- **Mantle 文档**: https://docs.mantle.xyz/
- **Arbitrum 文档**: https://docs.arbitrum.io/
- **Polygon 文档**: https://docs.polygon.technology/
- **IPFS 文档**: https://docs.ipfs.tech/
- **Pinata**: https://www.pinata.cloud/
- **RainbowKit**: https://www.rainbowkit.com/
- **OpenZeppelin**: https://www.openzeppelin.com/
### C. 参考项目
- Lap of Love: https://www.lapoflove.com/
- FurEver: https://www.foreverfur.com/
---
**文档结束**
*Last updated: 2026-04-12*