2025-11-20 01:17:04
距离上次跳槽有半年时间了，由于当时跳槽之后，接连不断遇到各种事情，一直没有时间和心情复盘一下，在那个 Restaking 项目的工作过程中，技术方面的经历。
项目遇到过一个疑难杂症，就是从其他链快速扫描出区块中的事件后，需要把扫描来的事件，通过 Cosmos 交易再提交到链上。问题在于，由于需要快速提交大量交易，不可能等待上一笔交易成交再提交下一笔交易，而链上的处理逻辑又明确要求事件必须确保顺序，也就是说，提交交易时候的 nonce 值管理至关重要。
之所以说这个问题是疑难杂症，是因为这个需求不是我负责的，对他（一个同事）来说属于疑难杂症，花了非常非常多的时间都没有解决好这个问题。
而且实话实说，这个问题根本没有技术含量。我当时一直在说，链下手动管理 nonce 值就可以。但是我不知道他到底处于什么样的考虑，是真的不理解我在说什么，还是刻意不想采用我的方案。总之反复出问题几次之后，都仍然没有采取我说的手动管理 nonce 值的方式。
为什么我说手动管理 nonce 值的方式可行呢？在更早的项目中，我需要发交易来压测以太坊客户端的交易处理能力以及出块的稳定性，把每个区块的使用量打满（Gas used 达到 3000 万），持续 2 天以上，然后观察每个服务器的资源占用情况。而用来压测的脚本，自然就是用少量几个钱包地址，快速发大量普通转账和合约调用交易的功能。
正因为有那样的经历，面对同样的类似的场景，我自然就会想到解决办法，而且实现起来很简单。
所以我觉得，可能因为他缺少这样的经历，真的无法明白该如何正确处理此类问题，而是把时间和精力都集中在失败交易的重试和兜底逻辑上，试图用失败补偿的代码逻辑去解决。这个问题最终的后果是什么呢，后果就是开发网搞了一个多月，功能依然都是不正常的，而后又赶鸭子上架，去上线测试网。测试网怎么办呢，根本都不敢开同步交易的功能。
我身处其中，才明白这个项目的可靠性有多么差。
我们的链，是一条基于 Cosmos SDK 的链。当测试网开放给社区后，遇到的第一个问题，就是网络突然分叉了，导致不能出块。
分叉的原因是踩了 Cosmos SDK 的一个依赖库方面的坑，有的节点会开自动裁剪数据的配置，有的节点不自动裁剪。而 Cosmos SDK 的某一个版本的 db 依赖，对于裁剪过和没有裁剪过的区块数据，会计算出不一样的 state root，导致网络分叉。
修复这个分叉的步骤是：1. 升级依赖版本，发布新的二进制；2. 让整个社区的节点配合，回滚一个区块。
搞笑的来了，Cosmos 的节点怎么回滚区块？我们的 Team leader 拉着他开了一个小时的会，发现 reset 命令不生效，没找到办法。后来他来找我会议，虽然我也没有直接的答案，但是在会议过程中，我去看了一下 Cosmos SDK 的源码，就知道原因了。答案就是 reset 需要带上 –hard 参数，否则只会回滚状态数据，不回滚区块数据……
而且毫不谦虚的说，关于链分叉的原因，也是我首先定位到的。我对比了我们服务器上， archive 节点和普通节点的区块信息，就发现了差异，然后进一步找到了普通节点上关于数据库的报错信息。
我为什么要强调这一点呢，因为当时在还不知道分叉原因的时候，他就把他的一个朋友（前同事）拉进会议，一起排查问题，而事实上没能带来帮助。
他的那个朋友据说挺厉害的，在 Cosmos 社区的大多数 PR 下，都能看到他朋友活跃的身影，属于 Cosmos 社区的忠实贡献者。他朋友当时在 Crypto.com 工作，年薪一两百万（人民币）的样子。
而且诡异的是，也许因为他的朋友 “厉害”，可能他就觉得自己也厉害？在日常的工作中经常表现出某种居高临下的态度。（其实我当时就心想，你的朋友厉害，关你什么事？）
顺便八卦一下，我当时的 Team leader，年薪也是一两百万的水平。
接着就要提到 Team leader 的问题，属于典型的 “大厂病”。
我们当时需要上线开发网，leader 找了一个外包的运维团队，让他们用 k8s 来部署整个链。出发点是好的，用 k8s 来规范化部署和管理。可是根本没考虑到外包人员的技术能力。负责写 k8s 的外包说，他之前根本没用过 k8s……
我当时看到运维在部署脚本方面和团队这边频繁沟通时，就在大群里提出过质疑，为什么非要用 k8s？直接 docker 部署上去不行吗？部署脚本根本不需要改，也不需要重写，部署开发网就一天之内的事。
我为什么敢这么说呢，因为我非常肯定，用 docker 部署也不会耽误网络运行。我们之前的项目几十个服务器没上 k8s，丝毫不影响主网的上线。而我就是实际写脚本、操作部署那些服务的人。
现在项目上线个开发网，一共就 2 个节点，怎么就用上 k8s 了？
而事实带来的残酷后果是，原本计划让外包团队一周写好部署脚本并上线，结果一周、两周、一个月……
不但老板定下的时间节点全盘延后，而且经过两个月的折磨，外包团队也主动辞职不干了。外包本身就是靠接活来挣钱的，但是却主动放弃了一个项目。这意味着什么？我大概能理解，对于外包团队来说，技术要求高，时间又短，对接的外包哥们是真的周末都在上班……
外包都能被逼到不想干了，我后来也不想干了，岂不是很正常的事情吗？
我们不是 “大厂”，但是我们的团队却遭受到大厂式做派的折磨。
大厂优先相信制度而不是相信人，由于人员众多、鱼龙混杂，所以需要依靠严格的规章流程，来保证事情的正确性。只要流程上是对的，事情的结果偏差就不会大。而对于小型的创业团队来说，应该首先相信人而不是制度。
我当时的一项工作，是搭建日志系统。在网络上线严重延期的情况下，让我集中精力去搞什么日志系统，完全是把力气花在了最没用的地方，影响上线进度不说，leader 对于日志系统，期望也是比较高的，他说你可能没见过那种专业的日志查询系统，完全支持键值对的方式，甚至支持对关键字的条件查询，我们希望也做成那样……不是，我们几个人啊，多大的团队，为什么要搞那么专业的运维系统。对我自己来说，出了问题直接看 docker 日志完全可以，而且总共就几个人，还都是程序员，搞那种可视化界面真是为了 “专业” 而专业。
当时的另一项工作，是搞一个链节点运行情况的监控面板。当时的运维同事让我印象深刻。这还不是那个外包来的运维，是团队里掌管着管理员账号、服务器权限的运维。
搭建 Cosmos 节点的 Grafana 面板需要什么呢？在 Cosmos 节点所在的服务器上，安装 exporter，然后 Grafana 来接入数据。就是这样的工作内容，运维完全搞不定。
我一开始是把这个事情交给运维干的，这本来就是运维的活，但是我发现事情迟迟没有进展，因为运维是真不会，他搞不懂什么 cosmos 节点、exporter 之类的关系，只要网上没有现成的教程，基本就是摆烂的状态。我一开始也摆烂，每天在大群里 @运维 一次，问他目前 Grafana 面板的进度，他有时候大概回一句，有时候干脆装死。总之就是没进度。
再后来我有时间了，就干脆自己梳理了一下 Grafana 的流程，从导出哪些数据，到自定义面板上的展示图表，然后自己动手搭了一套。真的很简单，两天搞定。而作为专业的运维，却至少两周都没能有进展。我当时真的没想到我需要亲自动手搭这种东西。
下一项工作，实现 Restaking 框架下的 VRF 随机数的生成和验证。
简单来说，leader 在和我讨论方案的时候，我能明显感受到他不懂 VRF，导致我都觉得无法沟通下去，而他一味的坚持自己对于 VRF 的理解。当然，后来他也调整了自己的说辞和设计，工作也大体上模糊的进行了下去。
为什么我说的如此含糊呢，因为从设计上，我觉得当时的实现方案没能体现出 VRF 真正的功效，但是又不想花费口舌给他讲明白、去说服他。
我现在可以大体说一下，当时的设计是，某一个节点生成随机数，然后由多个节点来对随机数进行验证。我的想法是，给多个节点相同的输入参数，让多个节点根据 VRF 生成相同的数字。
我的这个想法，当时说出来过，但是他没听懂，所以我就不想再多说了。事实证明，leader 在事后（我离职时的聊天中）承认自己了对于 VRF 的不懂。
这项工作的内容是，根据 Restaking 进来的代币权重，去影响 Cosmos Validator 的投票权重，进而影响节点的出块概率与出块奖励。
简短截说，leader 拉着另一个同事，设计了一周、review 了一周，又给了那个同事接近一个月的时间来实现这个需求。
事实上的结果是，这个需求在我接到手的时候，只完成了一些皮毛，定义了一些 proto 文件、GRPC 接口定义什么的。最核心的逻辑，关于如何获取到 Restaking 的代币权重、如何去更新 Voting Power 影响出块概率，都是留空的。
然后怎么样呢，我在一周的时间内，完成了这个功能的实现。当然时间有限，实现的不可能完全没有 bug，但至少功能已经跑通。
再然后怎么样呢，再然后我就跳槽了，后面的事情我也不知道了。
2025-11-17 22:36:29
2025-11-10 15:33:24
2025-11-03 15:37:35
有这样两个事实：
这样的事实背后是有原因的：
这会带来不同的现象：
所以区块链的技术世界中，有没有什么理论性质的 “真理”，是长久不变、可以复用、无论上层框架如何变化都不需要担心的？
区块链技术世界的三大真理：
掌握了这三个部分的技术，无论区块链形式上怎么推陈出新，无论行业热点如何变化，都不用担心，因为区块链本质上就是在解决这些问题。
怎么样才算是掌握了 “真理”？我看懂了、我理解了，算是我会了吗？算是我掌握了吗？
掌握真理的标准是，可以根据真理，从头构建出知识。
在计算机科学的世界里，假如世界毁灭了，给你一张纸和笔，你可以从头实现 lambda 演算、实现数据结构、实现一个解释器、实现一种编程语言，甚至构造出更多东西，不依赖于教材、框架、API，这叫掌握真理。
真理的意义在于，让你明白知识为何必须如此存在。——这也是王垠的课程在试图教会你的东西，王垠不教知识，只教 “王垠式真理”。所以我一直认为王垠的课程好、价值高。
类似的，在区块链的世界里，如果你可以从脚本写起，实现共识、加密、激励，不一定重建全部细节，但一定要理解现有系统为何那样设计，就差不多了。
要注意，智能合约的编程语言不在真理的范畴之内，无论是比特币脚本、Solidity、Move、Cairo，都只是表达交易逻辑的 DSL，都是在用不同形式，定义区块链执行交易的规则，很重要但是还没到 “真理层”。
非要说智能合约的真理层，可能可以表达为一个确定性的状态转移函数，无论语言如何变化，这个 “真理” 都始终存在：
State_t+1 = f(State_t, Transaction)下一个状态来自于上一个状态加上一些交易引起的状态变化，简单吧。但我们这篇文章重点关注区块链世界中的 “王垠式真理”，所以依然是三大真理：共识、加密、激励。
2025-10-24 00:55:34
到目前为止，最新的 AA（Account Abstraction）钱包规范仍然是基于 EIP-4337 实现的。
对于 AA 钱包存在的问题，像操作繁琐、Bundler 中心化、可用性低、生态支持不完善、合约安全风险高等表面上的问题就不多说了。
一句话描述 AA 钱包在干什么事情：AA 钱包能实现 “对账户资金的授权” 与 “把交易广播到链上” 这两个行为的分离。
AA 钱包的功能，体现到具体的交易行为上，就是如果没有 AA 钱包，你得自己发交易。有了 AA 钱包，你可以只签名，不发交易，让其他人代替你把交易发到链上就行。
为什么 AA 钱包能做到这一点？因为 AA 钱包本质上就是一个合约，所以你会发现，AA 钱包的大多数 “优点”，其实是智能合约本身就具备的功能，像什么社交恢复、批量操作等。唯一能带来特殊体验的，只有 “代付手续费” 这个特性。
那为什么 AA 钱包能实现代付手续费这个功能？因为 AA 钱包的所有操作实际上不是交易，而是 UserOperation，有一个链下的 Bunlder 程序会把这些用户操作，通过发交易批量提交到链上。
为什么以太坊需要 AA 钱包？因为以太坊的共识层协议要求，交易必须由一个 EOA 地址来发起。这个 EOA 地址，就是交易结构中的 from 字段，以太坊节点会从这个 from 地址计算手续费、扣手续费、验证交易有效性等。
合约没有私钥，交易不可能由合约发起。在这样的规则约束下，就导致以太坊所有的链上行为，都必须由某一个 EOA 地址来发起交易。
你可能觉得不对，部署一个合约，然后让合约来验证 data 里得签名数据就好了。data 里的签名数据，未必需要和发起交易的地址一致。
没错，事实上，AA 钱包的发展链路是：meta-transcations -> EIP-2771 -> EIP-4337。
这些方案在解决的问题本质上都是：如何让使用资金的权限，与发起链上交易的行为分离。
而引起这一系列复杂协议的根源，来自于以太坊 “交易必须由一个 EOA 地址来发起” 的规则。
为什么以太坊要有 “交易必须由一个 EOA 地址来发起” 这个规则？
因为以太坊的账户模型，是账户-余额模型。协议必须要知道，一笔交易的手续费从哪里扣。
比特币的 PSBT 交易格式，可以实现原生的多签。功能是多个钱包只负责签名，最终由另外一个钱包把交易广播出去就可以。
多签交易，就是典型的把对资金的授权，与广播交易行为分离开的场景。
为什么比特币不存在以太坊的这个问题？因为比特币使用的是 UTXO 模型，交易根本没有 from 地址，有的是多个输入脚本，节点只需要校验交易是否符合脚本的解锁规则，而不需要考虑手续费从哪里扣的问题。
我们梳理一下这个链条：以太坊使用账户-余额模型 -> 交易必须由 EOA 地址发起 -> 需要 AA 钱包。
AA 钱包在干的事情，实际上是在给以太坊的账户模型打补丁，为了修补账户-余额模型相比 UTXO 模型的不足，才有了 AA 钱包这个东西。AA 钱包是在不涉及以太坊协议变更的前提下，诞生出的一种 workaround 方案。
从地位上来说，AA 钱包对于以太坊的地位，类似于铭文/符文/RGB 对于比特币的地位。在比特币生态里，因为没有图灵完备的脚本，所以在不触及比特币协议变更的前提下，搞出了铭文/符文/RGB 这些 workaround方案。
AA 钱包需要链下的 bundler 来提交交易，与符文需要链下的索引器来维护符文的数据状态，是不是一个意思，都严重依赖于链下的程序？
而事实上我们都知道，比特币生态的玩法，至今都还没有被主流社会认可。
假如 AA 钱包未来有一天能被社会大众认可，那也就意味着 workaround 方案在区块链世界中是可行的。对于整个生态的叙事都将引起巨大的改变。
综上所述，我们能得出的结论是，以太坊永远不可能支持 “原生” 的 AA 的钱包（在协议层面支持）。
这些结论，对于技术人员的指导意义在于：