好久没写博客了，7 月份跟着装修完很累，又在上海呆了段时间，回来闲下来后发了个牢骚一直停到了现在，平时比较忙，除了干活就是陪媳妇看剧打游戏了，玩个手机都是奢侈，可以说是过上正常生活了，这才是正常的生活，忙忙碌碌，没啥时间。以前的时候漂泊在外打工，除了坐班工作，吃外卖，根本没啥事，闲的很，所以又搞开源又搞搞这搞搞那的，现在基本没什么时间关注自己的情绪。

我感觉在咱们这，不论什么行业不讲标准只讲良心……因为没什么规范可言。我这个房子装修时重新改了水，现在浴室里固定管子钉子全都生锈了。就算是恒洁的卫浴，装了三个钉子也生锈一个。厨房悍高的台盆还是奸商给我装的库存货搭配两个「纯铜阀门」的三无阀门。当时也没那精力研究和较真，太累了，什么不干坐工地一天都能把人急死。

好了，闲篇儿聊完了。先聊点正事最后聊聊 AI。

智能合约管理

简单来说就是要做可升级用多签钱包（MPC）管理，至于防黑天鹅（暂停、紧急提现）根据业务来看，一般来说是给非技术人员能够作为 backup 快速处理意外用的。

EVM

一般采用 UUPS Upgradable 或者 DiamondCut 架构或者有些业务场景会用到 Beacon 架构，升级权限交由团队管理的多签钱包（MPC），这里坑比较少，市面上例子非常多了，相关文档开发工具也比较成熟，只提关键词吧。

Tron

像 ZKsync 和 Tron 都是比较特殊的 EVM 链，为啥单单拿出 Tron 来说，因为 Tron 更加特殊一点 😂，他的 gas 模型比较特殊。如果你们准备赞助 transaction，就用一个公共的 deployer 部署你们的合约，方便统一进行赞助。

Solana

Solana 原生可升级，通过 BPFLoader 来执行升级，关键的方法就两个，一个 setAuthority，一个 upgrade，关键角色是 program 的 upgrade authority。这个 upgrade authority 是可以交给多签钱包管理的，前端构造一个升级交易就好了。

这里肯定不能这么简单，我要额外提一点就是自定义升级控制，比如说 30 天内是 A 可以控制升级，超过 30 天改为 B 可以控制升级该怎么做？答案是将 upgrade authority 交给 PDA，在 program 内部控制 PDA 调用升级，我用实操经验告诉你这是可行的，我就不手把手教你了，快十二点了我要睡觉了 😂，给你个小提示，可以在 Anchor.toml 里面定义创世数据，将 program 设置为可升级来编写测试用例进行测试。

Sui (move)

Sui 和 Aptos 算是将 move 魔改成了两个派系，Sui 的设计是非常好的，你写过他们两个平台的合约你就知道。Aptos 链的版本就比较混乱，像是农耕时代的产物。Sui 的链式调用和所有权都非常清晰，符合直觉，反观 Aptos 则是一团乱麻，如果 Sui 实现了忽略定义动态调用其他合约，它的开发体验一定不输 EVM 和 Solana。

Sui 管理是有一个 UpgradeCap 的 object，在部署时会交给 deployer。同样你可以把这个 Cap 转给团队的多签。我在这里还是问你，怎么自定义升级控制，你可以看官网文档的 Upgrade Policy 部分。将 Cap 作为 shared object，通过你合约的方法吐出 upgrade ticket 进行升级，小提示是你可以额外加测试框架比如 jest 运行一个 local node 来测试升级，sui move test 只测试升级外的业务。

Ton

Ton 这个链设计的太差劲，一个交易的多个消息可能在任意地方出错。还没真正做过合约，但是对他的交易构造和数据解析比较熟悉了，所以这里没什么指南了，只有一些心得。Ton 每个钱包都是合约，合约的实现是你自己选的甚至可以自定义，v3/v4/v5，第一笔交易需要 init，init 后你的使用其实就是调用你自己钱包合约的方法，不说了，没啥意思。

AI 漫谈

说起 AI 来我有点兴奋了，从 GitHub 给开源贡献者发 Copilot 开始我就在用 AI，因为之前大模型能力和 IDE 支持都不太行，也就一直在作为自动补全使用。慢慢大模型能力上来了，IDE 的花活更多了，事情就不一样了。我一直在用 Cursor，短暂的用过一个月 Claude Max Plan $100，Claude 是最舒服最牛逼的，Cursor 也不差。AI 写的又好又快，调调细节，来回几轮后就是很好的产出。

我曾经用一个下午时间通过 Claude 实现了一个 meme 发射平台包括合约、前端、简易后端（每个代币都是固定开头），你只要知道该怎么做作起来很快，现在完全看不到新牛马的未来，已经不是一行一行码字的时代了。