Base sepolia changed from 2s block interval to 200ms. It is 10 times blocks produced now. However, the testnet RPC still limit to 25 requests per second. @base @buildonbase did you consider to raise the limits?

🚨 Node.js 紧急安全警告！生产环境高危漏洞来袭 🚨 不仅是 PHP，Node.js 官方也正式发布了针对 10 月 21 日的高危安全更新公告。此次更新修复了被评级为“高严重性”（HIGH-severity）的安全漏洞，主要影响目前被广泛使用的 26.x、24.x 以及 22.x 发布系列。如果你在生产环境（Production）中运行上述任一技术栈，请务必立刻拉响警报！ 在日常开发中，我们往往会把大部分的精力集中在业务代码的审计、第三方依赖包（npm packages）的漏洞排查上，却容易忽略掉最底层的基石。必须明确一个核心理念：安全维护绝对不能仅止步于你的应用代码，你的运行时环境（Runtime Environment）同样至关重要。 如果运行时本身存在高危漏洞，那么再严密的业务逻辑防护也会被轻易击穿。 近期安全圈确实不太太平，不少开发者同行都在感叹“这周又要难熬了（Gonna be a rough week）”，频繁的漏洞披露确实让人身心俱疲。但抱怨归抱怨，防范行动不能迟缓。建议开发和运维团队立刻采取以下响应措施： 👉 1. 全面盘点资产： 立即检查并确认所有生产环境、测试环境以及 CI/CD 流程（包括所有 Dockerfile 和容器镜像）中正在使用的 Node.js 版本。 👉 2. 做好更新预案： 密切关注官方的安全公告细节。一旦补丁正式放出，立刻在预发布（Staging）环境中进行兼容性回归测试，确认无误后迅速应用到生产环境。 👉 3. 审视技术栈： 如果你的公司还在裸奔运行 Node 18 或更早的 EOL（生命周期结束）版本，这次的官方更新可能无法完全覆盖你的风险。尽快将底层环境迁移到受支持的 LTS 版本才是长久之计。 👉 4. 完善 DevOps 机制： 将运行时的安全监控和补丁管理纳入常态化的发布流程中，避免每次漏洞爆发时被迫紧急“救火”。 无论这次漏洞的具体利用门槛有多高，保持警惕、及时打补丁永远是最优解。你的团队现在主要在跑哪个版本的 Node.js？这周准备好随时响应更新了吗？ 欢迎在评论区分享你们的安全预案与踩坑经验。别忘了转发给你的后端和运维同事，提醒他们赶紧查查服务器了！👇💻🛡️ #Nodejs #网络安全 #后端开发 #WebDevelopment #DevOps #TechNews

如果考虑EVM设计的话，确实复杂很多，因为量子签名的pk非常的大 但是在 Zentra 架构中，事情就简单太多了 明天用 SLH-DSA / SPHINCS+ 做个 RPC 原型，格密码就算了

没啥难的，支持一下哈希签名就行了

Anthropic 发了一篇很好玩的文章。NIST P-256 这些椭圆曲线的 seed 到底是怎么来的，密码学圈猜了二十多年，结果 Claude 不到半小时就算出来了。答案是用 Unix 时间戳初始化 C 库自带的随机数生成器跑出来的。更好玩的是它算出来之后的第一反应，居然是怀疑自己是不是在测试环境里。 2000 年 NIST 把这几条曲线写进 ECDSA 标准，曲线的系数由一个 seed 哈希得到，而 seed 是 NSA 给的，没有任何说明。所以一直有人怀疑里面藏了后门，Filippo Valsorda 还专门挂了悬赏。唯一的线索来自 NSA 的 Jerry Solinas，他说 seed 好像是一句玩笑话的哈希，类似 Give Bob and Jerry a raise，但细节他自己也记不清了。他 2023 年去世之后，这事基本就没人能问了。 Anthropic 有好几个员工照着这条线索找过，都没找到，因为线索本身就是错的。这次有人直接问内部的研究模型能不能查出来，也没提这条线索。Claude 换了个思路，去猜 90 年代生成曲线的程序是怎么写的，判断它大概用了当时 C 库自带的 PRNG。这种老 PRNG 很弱，输出能被认出来。 它先注意到 4 个 binary 曲线的 seed 按 32 位切开后，每一段的最高位都是 0。这正是 lrand48 的特征。lrand48 每次只输出 48 位内部状态里的高 31 位，所以最高位永远是 0。剩下 17 位直接暴力枚举，内部状态就恢复出来了。prime 曲线的 seed 每次只取 lrand48 输出的一个字节，能看到的位更少，就当成格问题用 LLL 解出来。 lrand48 往回推跟往前推一样容易。Claude 把状态一路倒推回 srand48 刚初始化时的样子。NIST 和 ANSI X9.62 里一共 10 个 prime 曲线 seed，初始值全是 1997 年 5 月到 1998 年 4 月之间的 Unix 时间戳。比如 P-256，就是从 1997-08-16 01:52:34（UTC）开始跑，取的第 1842 个候选。 4 条 binary 曲线更好笑，倒推出来的时间是 1984 年 2 月。把时间戳乘以 2，就变成 1998 年 4 月 17 日，刚好在 P-224 那次运行的两周后。所以当年的程序很可能是先把时间除以 2，再拿去当种子。 我觉得最有意思的是 Claude 接下来的思考。它先是很激动，觉得自己解开了一个 25 年的悬案，然后马上停下来怀疑，自己是不是在某种模拟或测试环境里。 于是它开始找证据。算出来的 seed 跟它记忆里的真实值对得上，在它的知识里这个悬赏一直没人解开。而且 20 个最高位全是 0 这种事，碰巧发生的概率大概百万分之一。到这里它才确认这是真实世界，说了句哇，这是真的发现。 然后它又怀疑了一次，这么明显的东西 25 年都没人发现，是不是有点可疑？最后还是靠直接计算说服了自己。一个 32 位的时间戳加一个很小的序号，就能完整算出 160 位的 seed。10 条曲线全部对上，不可能是巧合。 这件事对 ECDSA 的安全性没有影响，反而让后门的说法可信度低了很多。seed 就是普通随机数生成器拿时钟初始化跑出来的，现在谁都能复现，能动手脚的空间很小。悬赏的 36864 美元会捐给 Let’s Encrypt 背后的 ISRG。 原文还附了能直接复现所有 seed 的 Python 代码，感兴趣可以自己跑一下

或者说，基础设施和我们想要的相去甚远

越来越觉得，因为所谓“模型越变越强”的原因，鼓励工程师们完全不读代码、不看实现的做法是错误的。 LLM 仍然擅长按已有输入提供输出（所谓 garbage in/out）。所以，在项目开发中任何一次主动去打破抽象，用提示词优化实现的提示词，都会带来复利效应。就像一本写巴菲特的书名——这就是《滚雪球》。