链上与链下的分工：保真与保快
一句话总结：链上保真，链下保快。
为什么要做链上 / 链下分工？
区块链并不是万能的后端。
虽然链上有很多优点，但也存在明显限制：
链上的优点：
- 公开透明
- 可验证
- 难篡改
- 规则执行可信
链上的限制：
- 成本高
- 速度慢
- 存储有限
- 查询复杂
- 不适合高频和复杂业务逻辑
因此，真实的 Web3 系统通常采用链上 + 链下协同，而不是“所有内容都写进合约”。
一、链上适合做什么？
原则：必须可信、可验证、不可随便改的内容，优先放链上。
1. 资产相关规则
如：
- Token 转账
- NFT 铸造
- Staking 质押/解质押
- Claim 领取
- 分红发放
- 权限控制下的资金划转
**原因：**这些操作涉及资产和核心规则，必须让所有人都能验证。
2. 关键业务规则
如：
- 谁能 mint
- 谁能 claim
- 一人只能领一次
- 总量上限
- 是否暂停
- 只有 owner/admin 才能执行特定操作
**价值：**不是你说了算，而是代码说了算。
3. 关键状态
如：
- 用户余额
- 是否已领取
- token 总供应量
- NFT 归属
- 地址质押状态
- 提案通过与否
这些都是“业务最终事实”，适合放链上。
4. 需要公开审计的记录
虽然不是所有日志都适合上链，但关键动作常配 Event，例如：
- Claimed
- Minted
- Deposited
- Withdrawn
- RoleGranted
方便链下同步和外部审计。
二、链下适合做什么？
原则：高频、复杂、便宜、强调体验的内容，优先放链下。
1. 用户系统
如：
- 账号体系
- 用户画像
- 登录态
- 偏好设置
- 运营标签
**原因：**更新频繁、不需全网共识，链上太贵。
2. 查询、搜索、列表、报表
如：
- 某用户最近 100 笔领取记录
- 活动排行榜
- 统计报表
- 多条件筛选搜索
- 后台分页列表
链上做这些既不经济，也不方便。
3. 缓存与加速
如：
- Redis 缓存热点数据
- 活动资格缓存
- 最近事件缓存
- 幂等标记
- 限流信息
这些天然属于链下。
4. 风控与运营逻辑
如：
- 刷号检测
- 异常行为识别
- 黑名单策略
- 资格审核
- 批量任务计算
- 活动规则统计
逻辑复杂、变化快，不适合写死在合约里。
5. 通知与产品体验
如：
- 交易成功提示
- 邮件通知
- 机器人提醒
- 运营后台展示
- 数据看板
全部属于链下能力。
6. 链上数据同步与索引
如：
- 监听 Event
- 入库
- 建索引
- 聚合统计
- 提供 API 给前端
本质：将“链上原始记录”转为“产品可用数据”。
三、实用分工判断法
设计时先问自己：
- 这个内容是否必须让所有人都验证一致？
-
- 是，偏链上。
- 这个内容是否高频变动、复杂查询、强调速度和体验？
-
- 是，偏链下。
四、真实案例：Claim / 空投系统
链上做什么
- 执行 claim（资产领取必须链上发生）
- 防重复领取（如：claimed[user] = true）
- 发放 token / NFT（资产变动需链上确认）
- 记录关键事件（如：event Claimed(address user, uint256 amount)）
链下做什么
- 计算谁有资格领取（如：任务、积分、规则）
- 存活动数据（任务记录、积分、审核、配置）
- 查询和展示（用户页面、后台、统计报表）
- 监听 Claimed 事件并同步数据库
关键理解：
最终领取动作必须链上，领取前的大量判断和运营逻辑适合链下。这就是 Web3 真实的分工模型。
五、再举一个例子：Staking 系统
链上做什么
- 质押、解质押
- 奖励规则执行
- 余额变更
- 关键状态保存
- 事件发出
链下做什么
- 收益统计页
- 排行榜
- 地址画像
- 用户历史记录聚合
- 报表
- 告警
- API 服务
一句话总结：
链上负责真金白银，链下负责看得见、用得顺。
非常实用的设计框架
拿到 Web3 需求时，建议分 4 层：
第 1 层：链上核心层
- 资产
- 关键规则
- 关键状态
- 权限
- Event
第 2 层：链下同步层
- 事件监听
- 数据入库
- 缓存
- 幂等处理
- 重试机制
第 3 层：业务服务层
- 用户资格计算
- 风控
- 查询 API
- 报表统计
- 运营逻辑
第 4 层：产品展示层
- 前端页面
- 后台页面
- 提示消息
- 搜索和筛选
- 图表
提示：
这个框架非常适合后端出身的你。
八、Java/Python 后端最适合切入哪一层？
建议优先专注于：
链下同步层 + 业务服务层
- 监听链上事件
- 同步数据库
- 做 API
- 做缓存
- 做风控
- 做统计
- 做后台系统
再补充一点合约能力，你就会变得非常有价值！
Claim 系统常见面试/思考题
- 在 Claim 系统里，谁发起交易？
参考方向：EOA / 用户钱包。
- 在 Claim 系统里，谁执行“是否允许领取”的最终逻辑？
参考方向：链上 Claim 合约。
- claimed[user] 这种数据为什么应该放在 storage？
参考方向：因为要长期保存并防止重复领取。
- 为什么 Claim 成功后要发 Claimed Event？
参考方向：为了让链下系统知道领取已经发生。
- 链下监听到 Claimed 后，通常会做什么？
参考方向：入库、更新缓存、统计、通知。
- 为什么“资格判断”很多时候先放链下做？
参考方向：规则复杂、变化快、查询频繁、成本更低。
- 为什么“最终是否领到”必须链上做？
参考方向：涉及资产和关键状态，必须可信、可验证、防绕过。
- 请用一句话概括 Claim 系统里的链上 / 链下分工。
参考方向：链下算资格，链上做最终执行，链下再同步结果做产品体验。
总结示例
在 Claim 系统里，用户通过 EOA 发起交易，链上合约负责最终校验和发放奖励，关键状态保存在 storage，成功后发出 Event；链下服务再监听事件、同步数据库、更新缓存并提供完整的产品体验。
