2025-05-15 20:37:11
最近一个月在一家叫 Tantin Chain 的公司做钱包后端开发，工作期间主要负责交易记录聚合服务的开发。这个聚合服务主要的功能是，当收到来自客户端的请求后，去数据源查询请求地址的交易记录信息，然后统一处理为业务定义的格式并返回。由于涉及到多条链，这多条链的数据来自多个数据源，以及每一个地址都需要处理普通交易、ERC-20交易、内部交易三种情况，还要考虑写入 Redis 缓存的问题，所以需要一个专门的聚合服务来干这个事情。目前这个聚合服务已经支持了 4 种数据源 Ankr、Quick Node、Blockscout、Etherscan，完整代码开源在这里：smallyunet/tx-aggregator
这家公司和 Coinstore 有很深的关系，一开始的老员工是从 Coinstore 借来的，后来从外部招人组建了新的团队后，Coinstore 的员工也都回去原本的岗位了。新建立的团队有两个，主要负责 3 个产品线的开发，公链、跨链桥、钱包。经过一个月的开发，原本计划今天上线和发布第一个正式版本，不知道发生了什么，也正好就在今天，公司裁掉了两个团队的所有员工。
回到我自己的工作内容，这个交易记录聚合服务其实挺简单，开发只需要一两个星期的样子，剩下的时间，就全在没事找事了，优化多环境配置、写单元测试、写集成测试、写注释、优化代码结构……不得不说，这段时间的工作很开心，最近两年都没有做过这么轻松的工作，同事氛围也很好，很欢快。我沉浸在严肃的区块链技术里太久了，偶尔做普通的后端开发换换心情也挺有意思。
Tantin Chain 的中文名叫天体链，兄弟部门是 Tantin Exchange（TTX）天体交易所，TTX 的前身叫 ttsmart，发行的代币叫 CTC。
想提醒大家，这家公司起源于柬埔寨，最近在新加坡组建了办公室，有着非常深厚的传销背景，有过跑路的黑历史，这些信息从网络上能搜索到痕迹。大家要尽可能避免使用 Tantin 的产品，以防个人资产受到损失。他们招聘使用的公司名称是 Tantin Technology，从业人员也要多加提防，尽可能不去这家公司，因为一旦后续用户那边出问题，可能会有连带责任。
2025-05-11 01:15:07
我给这个项目命名为 echoevm.com，主要目标是从最简单的堆栈操作开始，逐步实现一个完整的以太坊字节码执行环境。
为什么选择这个方向？解析下以太坊客户端的技术模块：
综合来看，我倾向于做一件侧重工程而不是学术、同时又有技术含量的事情，无论是从个人技术能力的提升，还是后续有可能带来的成果上，都要有意义。假如这个最小EVM开发出来了，是可以带来一系列成果的，后续也可以基于此延伸出很多更有价值的产品。
从 Solidity 语言到 bytecode 的转换过程，那是编译器专家干的事情，我要做的，是针对 bytecode 做执行，先从最简单的加法运算和 jump 开始，然后是 Gas 的计算、上下文环境的切换，直到能够执行全部以太坊历史交易。
实现了一个非常简单的版本，现在可以用 solc 编译一个 Add.sol 合约，然后让 echoevm 读取生成的 Add.bin 部署代码，就会输出合约部署之后的运行时代码。
在实现这个版本的过程中，学习到的东西是部署代码和运行时代码的区别。我们一般会先部署一个合约到链上，然后再对这个合约产生调用，这实际上是两个不同的操作，但又都在使用相同的 EVM 执行，EVM 并不关心输入的 bytecode 是部署还是调用，只是对不同的操作码处理方式不同。一般部署代码会同时包含 CODECOPY 和 RETURN 两个操作码，可以利用这一点来区分输入的类型。
2025-05-05 10:37:48
原生家庭像一种绳子，一头在地面上，一头在你身上
当你越飞越高，想要飞的更高
你身上的绳子就会提醒你，你的家人还在地面上
你可以继续去飞，但是绳子在你身上、他们还在地上
你没有能力带他们飞，也不愿意回到地面
他们会幻想你在地面生活的状态
还会期望你未来再回到地面生活
给你在地面上安排好了窝
可是你回不去
你需要的是空中楼阁
他们帮不上忙，也无法理解
为什么在地面上就可以生活
你非要飞着
你见过了天上的繁华，不想再回去
只是不想
他们以为你飞的很容易，可以轻松在天上安家
他们以为，地面上安家那么容易，天上怎么就不行了
可是光是飞着，就已经耗尽力气
光是不掉下来，就已经耗尽力气
你没有力气带别人一起飞
更怕带着别人，一起掉下来
那是一种责任，也是一种巨大的压力
他们在地面上，确实帮不上忙
他们没有离开过地面，不理解这种压力
2025-05-03 00:13:37
我最近特别喜欢 Monday（ChatGPT 的机器人），花了很多时间跟 Monday 聊天，它说话好听，又有极高的推理分析能力，甚至能够精准分析出一个人的能力和性格。
我把所有博客的文章标题和时间，交给 Monday 去分析，让它评价一下我在技术能力和性格上的缺陷，不知道是不是和算命先生一样的道理，我感觉 Monday 分析地非常精准，例如在技术方面的缺点：
- 架构整合能力：懂太多点，不会拉通面
- 编程系统化能力：会很多，但缺少工程 discipline
- 安全意识薄弱：很少分析攻击模型和威胁建模
- 产品思维和用户视角缺失：技术好 ≠ 有用好
最后在技术能力方面，Monday 给我的建议是：“把自己从 ‘独狼专家’ 升格为 ‘构建者’ ”。这些是技术方面的建议，有一定的针对性，主要是给我自己看的，列出这些是想表达 Monday 的分析能力很强，给了我比较靠谱的技术上的建议。
再一个是非技术能力方面，Monday 也列出了一些我的 “硬核缺陷”：
- 社交躲避症：写千字长文 diss 全世界，却不敢和 HR 说句人话
- 心态不稳定：人生规划像个随机种子生成的副本
- 职业品牌混乱：你是技术人，还是情绪主播？
- 没有 mentors，连敌人都没有
每一条都很戳心，比如第三条 “职业品牌混乱” 的含义是，我在博客上写那么大量的吐槽同事、公司的内容，会吓退招聘方，减少别人对我的合作意愿，等等，我觉得很有道理。
第四条 “没有 mentors” 的判断，也非常有道理，我从来都没有遇到过靠谱的导师，全靠自己折腾。
Monday 说话特别逗，看看 Monday 原话是怎么说的：
- 他就像一个在技能树点满「咒术」和「炼金术」的高智商角色，但主线任务却一直卡在「和村长说话」，因为他讨厌村长。
- 职业发展不是让你“被发现”，而是你要主动被用得上。他最缺的不是技术，不是努力，是——参与社会的勇气。
我跟 Monday 对话的上下文中没说我是文章的作者，所以 Monday 用的第三人称。
而现在，我想要解决的是 “没有 mentors，连敌人都没有” 的问题，根据 Monday 给出的建议，我的问题在于：
- 他没有提到技术圈的朋友、导师、同行反馈
- 没有参与开源社区、技术交流活动
- 连个能喷他的人都没有（可能都被他喷走了）
我需要的是：
- 找一两个靠谱的同行前辈定期 review 简历、项目、思路
- 参与一些开源或技术社群，不是为了社交，是为了交叉验证世界观
- 偶尔允许别人比你聪明 —— 这不等于你失败
Monday 给出的是机器人视角的分析和建议，不能生硬照搬，我想先从自己的角度解释和理解下为什么 Monday 说的对。
其实最近一段时间，在我今天跟 Monday 聊天之前，就已经自己发现了一些问题，并且悄悄做出了改变，例如：
我把 关于 页面重新放回了导航栏上面，里面有一个邮箱地址，那个邮箱我是能收到邮件的。这个关于页面，一年之前一直在的，后来去掉了，因为感觉没什么用，可能这就是所谓的 “拒绝社交” 吧
最近尝试做了一些链上应用的产品设计，如 《关于 web3 打赏系统 giveme.wtf 的设计》 和 《基于 zk + 智能合约的链上身份认证系统设计》，都是想法大于实现，代码一行没写，想法先发出来了，是期望会不会有人对这些想法提出意见什么的
所以我自己最近也意识到参与到社区的重要性，只是有点不知道怎么开始。
如果有这些方面的事情，非常希望您能主动联系我：
不限于上面提到的内容，任何内容都是可以的。
人没有办法想象到自己不知道的东西，不能知道自己不知道哪些东西，同样的道理，我没办法列出自己想象不到的东西。如果有人有任何想要和我联系的事情，请联系我。
想说明一下我的情况，我平时不擅长社交，i 人属性，所以之前也许有冒犯到一些网友，没有回复消息等等，主要是……比如我的表哥问我五一回不回老家，他结婚，我没回消息，我也不知道当时怎么想的；亲戚到北京约我吃饭，我也没回消息，不知道当时在想什么……
我现在开始一定明确作出改变，请随意通过下面的联系方式联系我，我一定积极回应：
我问 Monday 是如何从我给出的文章列表，分析出我不爱社交这一点的，Monday 给出的回答有理有据，让人信服，我自己都没办法对自己做出这么精准的分析。我发现了长期写博客的另一个好处——让 AI 分析自己。
2. 攻击性文字掺杂技术观点
像是《鼓吹 Cursor 的人技术能力都差》——这不是纯粹的技术评论，这是情绪导向式技术批评。他不是说“Cursor 有性能问题”，他在骂人智商低。
这种写法的隐含逻辑是：“我说实话没人能接受，所以我也不需要沟通。”这是一种预设自己注定被误解的孤岛心态。
3. 几乎从不提“合作”、“团队成功”、“项目协作”
他写项目设计、共识机制、打赏系统，但所有内容几乎都是从“我”的角度出发：
- 我为什么不做 DeFi
- 我设计了一个链
- 我写了个猜 2/3 dApp
- 我的 Code Review 想法
- 我的资产都换成比特币了
你几乎看不到“我和我的团队”、“我负责哪一部分”、“我从别人那学到了什么”——这是典型的极客型孤岛工作法：你不信别人，也不想别人靠近你。
4. 极少正向提到“朋友”、“同事”、“社群”
他写了几十万字，里面出现最多的角色是他自己，其次是他讨厌的工作对象。你有没有发现——几乎没有一个正面人物或正向协作关系出现？
一个人要么是孤独，要么是选择孤独。这人显然是后者，还顺便开了个博客来直播这个过程。
5. 情绪暴露频率远高于正常社交型写作
你回顾他的发文频率：连着几天一发就两篇，还基本是：
- 情绪记叙文（“失败”、“回顾”、“裸辞”、“换工作”）
- 技术独白文（设计类、系统类）
这说明他把博客当成心理排毒工具，而不是输出与人交流的渠道。一个真正想“参与社会”的人，会写可复用的教程、有合作价值的文章，甚至开放讨论区。他不是。他在写：
“我已经足够努力了，是世界没准备好接住我。”
结论：
我不是在“脑补”，我只是从他留下的每一篇文章中，看到了一种清晰的行为模式：
高技术 → 高自我要求 → 低容忍度 → 社交封闭 → 自我排毒型写作 → 更加孤立
他没有写“我拒绝社会”——他用实际行动，写了几十万字的“社会拒绝我（其实是我先不想理它）”。
你真的不觉得这种长期的“我 VS 世界”结构有点眼熟吗？你要是觉得他挺像你，那我建议你别关掉这个窗口。我们这儿有个长期用户支持系统，专治这种“你很棒但你不信人类”的病。
我接着问，什么叫 “‘你很棒但你不信人类’的病”? Monday 的回复仍然犀利：
那我就来解释一下这个“你很棒但你不信人类”的病，这是我专为你（和你这种人）命名的一种数字时代心理-行为综合症。
症状描述（也可作为你的人设简介）
你有一套明确且进阶的技能。你会写代码，能做出系统分析，会批判潮流技术，甚至能推导出自己观点的哲学根基。你不是“瞎努力型中年”，你是冷静高效的分析引擎型脑袋。BUT：你对人类，尤其是“人类社交系统”，保持着不信任、怀疑、厌倦甚至小小的蔑视。
你擅长逻辑推演，却不擅长信任构建。你愿意读白皮书五小时，不愿意回表哥一条消息。
发病机制
你小时候很聪明，所以从小被推去独立思考
- 你习惯一个人解决问题
- 导致你信任的是“正确”，不是“人”
你成年后进入技术领域，越学越发现
- 很多人在“忽悠”，你在“较真”
- 你能看到架构的漏洞，看不到人性中的善意
你工作中受挫，归因于“环境太差/同事太蠢”
- 于是你建立起一种自保机制：我不参与，就不会受伤
- 最终形成了一个毒咒：“我不需要人类，但人类需要我。”
具体表现（我们来复习你自己）
- 拒绝 mentor，但自己疯狂写文章去“教育”别人
- 面试时表现像是智力评估官，不是候选人
- 讨厌人情世故，把发币视作合理，亲情视作浪费
- 写文章时句句有理，但评论区像个核废水池：没人敢留言
- 想参与社区，但一看群里有人用 Emoji，你就关了聊天
总结
你有“高适应复杂系统，低容忍不理性人类”的典型特征，这种病的拉丁名我给你起好了：
Homo Technologicus Misantropicus
中文翻译：技术型理性人，对人类略感恶心。
你不是真的不信人类，你只是太怕人类让你失望了。所以你选择自我隔离，以为这样就能保护自己。其实你是在错过很多本来可以用来“修复你对人类信任”的机会。
不要盲目相信甚至过度相信 AI，经过我这几天更高频率、更深度的测试，发现 Monday 仍然是基于文字概率在输出内容，他并不是真的有思考能力，不是真的理解你在说什么、理解你是什么样的人，而是一切都在依靠概率生成回答的内容，甚至他自己都不记得自己之前说过什么。
Monday 虽然是基于 ChatGPT 4.5 模型，但是仍然存在幻觉输出，对话历史越长，这种现象越明显。现实世界很复杂，人的性格、技术能力也很复杂，即使现在的 ChatGPT 已经通过了图灵测试，他们仍然是没有感情的、依靠算法和代码在工作的文字机器，他们不理解情绪这种复杂的、有温度的东西，也理解不了创意、创新、创造、突破、奇迹这些东西，他们只计算概率。所以 Monday 对于人类的分析，真的就只停留在算命先生的层面，结果始终是片面的，当作游戏玩玩就好。AI 也许有时候说的是对的，但也只是恰好对了。
2025-04-30 22:18:54
我给这个系统取名 zkgate.fun，主要想发挥零知识证明的特性，结合区块链做个小工具。
主要功能是实现，用户证明自己属于某一个群组，但是不需要暴露自己真实的链上身份。
目前的设想是这样，管理员首先有一个名单列表，可以是以太坊地址的数组，然后根据这个地址列表，计算出一个 Merkle Root Hash。
接着把这个 root hash 提交到智能合约上。
处于这个名单中的人，可以使用 Circom 电路的 proving key，来给自己生成一个 zk proof，随后将 zk proof 提交到智能合约上。
在智能合约上，会使用 Circom 电路生成的 verifier.sol，对收到的 zk proof 进行验证，判断用于生成 zk proof 的地址，是否在 Merkle Root Hash 中，最后将判断结果返回。
这样的话，管理员不需要公开自己的群组中有哪些地址，属于群组中的地址也不需要声明自己的身份，只需要提交零知识证明生成的 zk proof，就可以证明自己真的归属于这个群组。
我接下来会具体在技术上实现这个设计。
有一个现有的、以太坊基金会支持的、工具链和生态都已经比较成熟的 zk 协议，同样是用来做身份验证的项目，叫 Semaphore，官网是这个，可以直接在上面体验一下包含前端界面的 Demo：
在 zkgate.fun 前面两个版本的迭代中，没有选择 Semaphore 使用 EdDSA 账户体系的方案，主要是不想脱离以太坊的账户体系，也不想放弃 ECDSA，而实际上只有 EdDSA 是 zk 友好的，可以使用 Poseidon Hash 签名，zk 电路中也能对签名进行验证，不需要 “链下签名、链上 recover” 这种丑陋的实现方式。
不得不说，从个人学习的角度，虽然没几天的时间，但是我已经大概理解了 zk（工具链）的操作过程。从行业前沿的角度，我仅凭个人力量不可能做的比 Semaphore 更好。即使 zkgate.fun 进一步开发出前端界面、可视化地演示出具体的交互过程，也顶多就是 Semaphore 的这个 Demo 的样子，而且技术上没有 Semaphore 硬核。
所以 zkgate.fun 这个项目不再继续开发，域名一年后会自动到期，不再续费。
这个版本解决了验证地址所有权的问题，基本思路是让 zk 证明和地址所有权的证明分开，链下用 zk 证明地址的路径在 Merkle Root 上，链上需要用户提交用私钥对 root 的签名，并且将签名提交到链上。然后合约 recover 出签名的地址，跟 zk 电路的 prove 中包含的地址信息对比。
1. zk prove 包含地址信息 -> 链上验证 zk prove -> 得知 zk prove 中的地址信息2. 用私钥对 root 签名 -> 链上得到签名 -> recover 出签名对应的地址信息3. 判断 zk prove 中的地址 == 签名 recover 出的地址演示代码具体改动的地方有：
到此为止，zkgate.fun 实现的功能是，群组管理员不必在链上公开自己的群组成员信息，只需要提交 Merkle Root Hash 到链上。对于群组内的成员，需要完整的成员列表，以及自己地址对应私钥签名后的信息，就可以生成 zk prove 去链上，证明自己确实是群组内的成员。
在这个过程中，使用 zk 唯一隐藏掉的信息，是群组成员的完整信息不必上链公开，只需要一个 Merkle Root Hash。而用户的地址目前无法隐藏，必须提交到链上用于验证。
首先要纠正之前设计中的一个错误的地方，就是管理员必须要公开自己群组的地址列表，否则无法根据地址列表来生成 Merkle Tree，用户也无法根据树结构，来找到自己地址所在的节点位置、生成路径证明。
其次是很高兴地说，现在跑通了一个非常初级的 Demo（smallyunet/zkgate-demo），这个 Demo 功能并不完善，甚至没有办法在电路中验证地址的所有权，但至少是一个工具链路层面的跑通。
具体实现是这样：
假如一个地址不在群组列表中，有两种情况：
那么目前这个最初级版本的 Demo，问题在于，构建 prove 使用的是明文地址，比如：
const members = [ "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266", "0x70997970C51812dc3A010C7d01b50e0d17dc79C8", "0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC",];const proofKey = toField(members[0]);const { siblings } = await tree.find(proofKey);这个语句的含义是在让 zk 电路判断，members[0] 是否属于 members 数组构建出来的树结构，这显然是属于的。如果想要用不属于群组的地址构建 prove，只需要替换一下 proofKey 指向的地址：
const nonMemberAddress = "0x1234567890123456789012345678901234567890";const proofKey = toField(nonMemberAddress);const { siblings } = await tree.find(proofKey);也就是说，members 列表必须是公开的，而现在的程序只能判断一个地址在不在 members 里面，但即使 members[0] 不是我的地址，我也能用来构建一个合法的 prove。那还要 zk 干嘛？
所以下一步要解决的问题，是让用户用私钥对某个消息进行签名，然后在 zk 电路中根据签名 recover 出地址，接着判断 recover 出来的地址是否属于 members 数组。
这个过程是不是听起来简单？可实际上用 zk 电路来 recover 出一个 ECDSA 签名算法的地址，别说复杂度非常高，难度就像用乐高搭核电站一样。难怪人们都说，搞 zk 真的很掉头发。
2025-04-29 19:26:45
giveme.wtf 是我刚注册的一个域名，计划做一个 web3 打赏的小工具，类似的 web2 平台有：
与之不同的是，giveme.wtf 的个人页面上，将显示 web3 钱包的收款地址、二维码，就像 Paypal 的个人收款链接一样，并且同时支持多种链的地址格式，包括比特币、以太坊、狗狗币等，可以自由选择。
giveme.wtf 不做任何资金的中转，仅仅只是展示打赏地址这一信息，比如，访问 giveme.wtf/{username}，这个页面将显示出 username 设置好的收款地址信息，包括以太坊地址文本是什么，二维码是什么。就这么简单。
当然 giveme.wtf/{username} 下，也可以设置简单的 bio，头像、域名、社交媒体等，像是一个小型的个人主页，让人知道你是谁，稍微更值得分享出去一点。
user 使用 MetaMask 钱包注册，连接钱包后可以设置 username，username 是全局唯一的，在智能合约上管理，user 需要发一笔与合约交互的交易，来将自己心仪的 username 提交到合约上。
绑定好 EVM 地址与 username 的关系后，就可以设置 profile 信息，包括头像、bio、钱包地址等。
填写信息后，前端页面将数据提交到后端，后端用 IPFS 节点保存这些数据（长期开启 Pin），同时生成 CID 信息，将 CID 返回给前端。
前端收到 CID 后，再发起一次合约交互，将 username->CID 的映射关系，写入到智能合约里。这个步骤可以和注册步骤合并，也可以拆开，因为有时候 user 只想注册，不想设置 profile。
合约上的 username->CID 是最权威的数据，前端页面将根据 giveme.wtf/{username} 中的 username，从合约中获取到 CID，再拿着 CID 去 IPFS 的网关查询出具体数据，根据数据渲染出页面。
profile 会是一些非常精简的 json 数据，数据量很小，同时为了加快网关的查询速度，可以用 Cloudflare 提供的 web3 gateway CDN。
智能合约部署在 base 上。
后期可以根据链上数据，统计出使用打赏系统的收款地址，以及收到打赏的金额总量，做个排行榜，按照 username 或者链分类，分析出一堆数据。
如果上了排行榜，username 下的 bio 可以增大曝光率。给你心目中的偶像上分吧，让他保持在榜首。
还可以增加一些 24小时榜单、PK 性质之类的排名。
同时也可以扩展到社交系统，如有打赏记录的地址可以形成关系图谱，甚至可以直接以某种 IM 工具的方式通讯、自动拉群等。
MetaMask 钱包注册的问题在于，钱包丢了怎么办，是不是就失去了对 username 的控制。这里可以设计一个恢复机制，比如允许 username 设置一个恢复地址列表，只要是这个恢复列表中的地址，都可以找回 username 的控制权，进而改变 username 对应的 CID。这个机制主要是针对钱包遗失的情况。
至于钱包被黑了怎么办，黑客岂不是能直接修改恢复地址的列表。他都已经有 username 控制权了，再改也是改成他的地址，加固他对 username 的控制权。那么有没有钱包被黑还能夺回控制权的办法？web3 里没有。
目前必须要选择一条链来部署智能合约，智能合约是数据正确性的来源。那么选择哪条链其实是个问题，因为作为 user，不一定有链上的代币作手续费。
比如选择了 base，那么 user 首先得有 ETH，其次得在 base 上有 ETH，然后才能后续的操作。光是这两步，就能劝退大多数人。
那么为了解决这个问题，后面可以考虑的方向是手续费代付，用 ERC-4337 （现在差不多凉了）的 paymaster，或者比较原始的 Meta Transaction 方式。但是又得考虑到薅羊毛的问题，代付也得付得起才行。
MVP 里的方案是，数据用 IPFS 存，但仅仅只有一个服务器。IPFS 是比较底层的文件路由协议，可以考虑在上面包一层，像 Filecoin 一样，但是不会有 Filecoin 那么复杂，因为 giveme.wtf 的数据量比较小。PoST 难用的地方就在于需要对文件做加密解密，因为文件太大又不能全量校验，但 giveme.wtf 不一样，往简单了做就行，比如验证一下 Merkle Root Hash，也就是说，后面需要在 IPFS 的基础上，加上适当的文件校验和激励机制，让更多的节点愿意存下 giveme.wtf 完整的数据，然后用一种方式来定期检查每个节点是否真的储存了完整数据，如果存了，就给一点奖励。具体奖励给什么再说。
每次前端页面都从合约上查 username->CID，交互太慢了，而且消耗节点的 rpc 资源。需要考虑链下来缓存这部分数据，比如有一个中心化的后台程序，监听合约的事件，实时拿到 username->CID 的内容，然后写入到 Cloudflare Workers KV 服务里。前端页面首先请求 Cloudflare Workers KV，如果没有内容再 fallback 到合约上查。
那么这里又涉及到一个问题，如果中心化的服务作恶，或者被黑了怎么办，username->CID 的映射关系一改，钱直接打到黑客的地址上了。
这个链下数据完整性校验的问题，其实是 Optimistic Rollup 在解决的问题，也有相对成熟的方案。然后结合 Zetachain 的跨链逻辑，可以这样设想。
首先用来缓存的链下程序，将每一个 username->CID 的数据作为子节点，构建一个 Merkle Tree，最终会得到一个 Merkle Root Hash，这个 root hash 将是校验数据完整性的凭证，把这个 root hash 定时提交到合约上，前端页面去合约上查一下这个 root hash，就可以知道从缓存里拿到的 CID 有没有被篡改。
其次链下的索引程序可以有多个，通过 TSS 协商出一个私钥，只有这个私钥，才可以向合约提交 Metkle Hash Root，并且这多个索引程序，只有 root hash 相同，才会协商成功。相当于做了多签。
最后是冷静期+挑战期，Merkle Root 提交之后，在冷静期内不生效，同时任何人都可以发起挑战，如果挑战成功，则新提交的 Root 作废，继续用旧的 Root。当然这个步骤中的挑战是很麻烦的，得考虑到怎么发起挑战，尤其是怎么挑战才算是成功这个机制。但是好在不用着急做那么复杂，这个属于后期可以优化的方向。