距离上次跳槽有半年时间了，由于当时跳槽之后，接连不断遇到各种事情，一直没有时间和心情复盘一下，在那个 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，但至少功能已经跑通。
再然后怎么样呢，再然后我就跳槽了，后面的事情我也不知道了。