giveme.wtf 是我刚注册的一个域名，计划做一个 web3 打赏的小工具，类似的 web2 平台有：
与之不同的是，giveme.wtf 的个人页面上，将显示 web3 钱包的收款地址、二维码，就像 Paypal 的个人收款链接一样，并且同时支持多种链的地址格式，包括比特币、以太坊、狗狗币等，可以自由选择。
giveme.wtf 不做任何资金的中转，仅仅只是展示打赏地址这一信息，比如，访问 giveme.wtf/{username}，这个页面将显示出 username 设置好的收款地址信息，包括以太坊地址文本是什么，二维码是什么。就这么简单。
当然 giveme.wtf/{username} 下，也可以设置简单的 bio，头像、域名、社交媒体等，像是一个小型的个人主页，让人知道你是谁，稍微更值得分享出去一点。
后期可以根据链上数据，统计出使用打赏系统的收款地址，以及收到打赏的金额总量，做个排行榜，按照 username 或者链分类，分析出一堆数据。
如果上了排行榜，username 下的 bio 可以增大曝光率。给你心目中的偶像上分吧，让他保持在榜首。
还可以增加一些 24小时榜单、PK 性质之类的排名。
同时也可以扩展到社交系统，如有打赏记录的地址可以形成关系图谱，甚至可以直接以某种 IM 工具的方式通讯、自动拉群等。
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 上。
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。当然这个步骤中的挑战是很麻烦的，得考虑到怎么发起挑战，尤其是怎么挑战才算是成功这个机制。但是好在不用着急做那么复杂，这个属于后期可以优化的方向。