看到大家认可那些为协议增加硬不变量(hard invariants)的升级总是让人很高兴——这些改动能够提升协议安全性,并增强未来的适应能力。 2021 年:EIP-2929 + EIP-3529(提高 SLOAD 的 gas 成本、削弱退款机制) 2024 年:SELFDESTRUCT 削弱(Dencun 升级) 2025 年:每笔交易 16,777,216 gas 的上限 这些改动为单个区块或单笔交易中可发生的操作量设定了不同形式的硬性上限,彻底消除了整类 DoS 风险,使客户端代码能够进一步简化,并为提升效率开辟了更多选择。 我预计我们很快还会需要以下不变量: 限制可访问的合约代码字节数(短期:提高调用大型合约的成本;中期:采用二叉树结构 + 分片计价) 为 ZK-EVM 的证明器 cycles 设定上限(通过重新定价机制实现) 调整内存计价方式 以建立 EVM 最大内存消耗的更清晰硬性上限。 Always glad to see when people appreciate the protocol changes that add hard invariants, improving protocol security and future adaptability 2021: EIP-2929 + 3529 (SLOAD gas cost increase, refunds nerfed) 2024: SELFDESTRUCT nerf (Dencun) 2025: 16,777,216 gas per tx limit All of these put various kinds of hard caps on how much can happen within a single block or a single transaction, eliminating entire classes of DoS risk, enabling client code simplification, and creating more options for how to increase efficiency. Invariants I expect we will want soon: * Cap number of code bytes accessed (short term: increase cost of calling big contracts, medium term: binary tree + per-chunk pricing) * Bounds on ZK-EVM prover cycles (repricings) * Changes to memory pricing to create a clearer hard bound on max EVM memory consumption
目录
观点原文
看到大家认可那些为协议增加硬不变量(hard invariants)的升级总是让人很高兴——这些改动能够提升协议安全性,并增强未来的适应能力。
2021 年:EIP-2929 + EIP-3529(提高 SLOAD 的 gas 成本、削弱退款机制)
2024 年:SELFDESTRUCT 削弱(Dencun 升级)
2025 年:每笔交易 16,777,216 gas 的上限
这些改动为单个区块或单笔交易中可发生的操作量设定了不同形式的硬性上限,彻底消除了整类 DoS 风险,使客户端代码能够进一步简化,并为提升效率开辟了更多选择。
我预计我们很快还会需要以下不变量:
限制可访问的合约代码字节数(短期:提高调用大型合约的成本;中期:采用二叉树结构 + 分片计价)
为 ZK-EVM 的证明器 cycles 设定上限(通过重新定价机制实现)
调整内存计价方式
以建立 EVM 最大内存消耗的更清晰硬性上限。
Always glad to see when people appreciate the protocol changes that add hard invariants, improving protocol security and future adaptability
2021: EIP-2929 + 3529 (SLOAD gas cost increase, refunds nerfed)
2024: SELFDESTRUCT nerf (Dencun)
2025: 16,777,216 gas per tx limit
All of these put various kinds of hard caps on how much can happen within a single block or a single transaction, eliminating entire classes of DoS risk, enabling client code simplification, and creating more options for how to increase efficiency.
Invariants I expect we will want soon:
- Cap number of code bytes accessed (short term: increase cost of calling big contracts, medium term: binary tree + per-chunk pricing)
- Bounds on ZK-EVM prover cycles (repricings)
- Changes to memory pricing to create a clearer hard bound on max EVM memory consumption
ABAB AI 解读
白话解读(通俗到不行的版本)
说的其实就一句话:给以太坊加“硬性限制”,就像给系统上安全护栏,让它更安全、更稳定、更不容易被卡死或攻击。
过去几年,以太坊一直在做一件事:给各种操作设定“硬上限”——不允许单笔交易或单个区块做太多事。
为什么要这样做?
因为如果没有这些限制:
- 有人可以在一笔交易里做“超级复杂的大操作”
- 可能会把节点电脑直接“算爆”
- 整个网络就会被拖慢、卡住,甚至被攻击
所以以太坊团队不断推出升级,目的都是:“不要让任何一笔交易把整个系统搞崩。”
比如:
- 降低 SELFDESTRUCT 权限
- 提高某些操作的成本
- 给交易 gas 上限
- 减少能一次性改动的东西
这些就是给系统“加硬规则”。
未来还要加的护栏是什么?
他列了三个方向,用白话解释就是:
1. 限制“大合约”的读取量
大合约太大、太复杂,一旦有人疯狂调用,会让网络变慢。
→ 所以要限制“合约越大,调用成本越贵”。
2. 限制 ZK-EVM 的计算量
ZK 证明可能超级耗算力,如果不加规则:
→ 某些交易可能需要“算半天”,把系统拉垮。
所以要加上限,让计算量受控。
3. 调整内存价格
不能让某些交易无限占用内存空间,否则:
→ 网络节点会被挤爆。
所以未来也要给内存使用加上硬性天花板。
一句话总结
以太坊正在全面“加护栏”,避免任何人用一笔交易就把网络卡死。未来还会继续强化这些护栏,让系统更稳、更快、更安全。
相关观点
- 我认为人们有时迟迟不愿意更彻底地转向 Signal 的一个原因(当然不是唯一原因),在于他们已经形成了一种使用习惯:把 Signal 当作“高优先级、无干扰”的收件箱,而把 Telegram 当作“其他所有人都在这儿联系我”的收件箱。正因为如此,他们会犹豫是否要让 Signal 再次变得“杂乱”。 在这种情况下,我发现以下做法对我很有效: Signal 现在已经支持文件夹功能:你可以在联系人上右键(手机端则是长按),会出现“添加到文件夹”的选项。 使用另一个应用作为高优先级收件箱(例如 Session、SimpleX):这样既能保持 Signal 不被过度打扰,也是在支持那些试图实现更强隐私属性的项目。 另外,开始培养一个习惯:当有人在 Telegram 上联系你时,直接问一句:“你用 Signal 吗?我在那边的用户名是 <username>。” 然后把这段对话转移到 Signal 上。 One reason (not the only reason) why I see people sometimes hesitating to switch more fully to Signal, is that they got into a habit of using Signal as their "high-priority, clutter-free" inbox and Telegram as their "everyone else talk to me" inbox, and thus hesitate to make Signal "cluttered" again. Things that I find work for me in this situation is: * Signal now has a folders feature: you can right-click (if on phone, tap-and-hold) on a contact and an "Add to folder" option appears * Using *another* app (eg. Session, Simplex) as your high-signal inbox, this way support projects that are trying to achieve even stronger privacy properties Also, start to build a habit: when someone contacts you on Telegram, ask: "are you on Signal? I am <username> there", and move that conversation over to Signal.Vitalik Buterin · 2026/02/09
- 这是一个很好的决定! ENS 名称和记录是一种“状态(state)”,它们处在以太坊生态系统的核心位置。这种状态在规模上是受限的,同时又具有很高的价值,因此越能在任何地方被便捷访问,就越有价值。 它同时也是一种半金融应用:因为购买和持有 ENS 名称本身是有成本的,而且 ENS 名称有可能成长为非常有价值的资产。 随着以太坊扩容路线图的推进,以太坊 L1 是承载这类应用的理想位置。 更广泛地说,我认为去中心化身份和社交(我认为 ENS 就属于这一大类)的最优架构是: 将每个用户的账户与个人资料数据放在 L1 上; 再使用专用型的 L2(很可能比完整的 EVM 简单得多)来处理用户行为,例如社交平台上的各种操作。 It's a good decision! ENS names and records are a form of state that is central to the Ethereum ecosystem, the state is limited in size and there is high value in it being as accessible as possible from anywhere. It's also a semi-financial application, in the sense that buying and holding ENS names has a cost, and ENS names can become very valuable objects. With the expanded scaling roadmap, Ethereum L1 is the ideal place for these applications. More generally, I expect that the optimal architecture for decentralized identity and social (the general space I see ENS being in) is to have this kind of per-user account and profile data on L1, and to have special-purpose L2s, likely much simpler than full EVMs, to handle user actions (eg. actions on social platforms).Vitalik Buterin · 2026/02/07
- 我一直在关注大约 1.5 天前我对 L2 发表看法之后的各种反应。 我坚信的一件重要事情是:“再做一条 EVM 链,然后加一个到以太坊、延迟 1 周的 optimistic bridge”,在基础设施层面,就像分叉 Compound 对治理的意义一样——这是我们已经做了太多、持续太久的事情。因为我们变得过于舒适,这种做法消耗了我们的想象力,把我们带进了一个死胡同。 如果你做的是一条没有 optimistic bridge 连到以太坊的 EVM 链(也就是一条 alt L1),那就更糟糕了。我们根本不需要更多复制粘贴式的 EVM 链,也绝对不需要更多新的 L1。 L1 本身正在扩容,并且会带来大量的 EVM 区块空间——不是无限的(尤其是 AI 应用,将需要比大幅扩容后的 L1 还要更多的区块空间和更低的延迟),但已经是很多了。 请去构建一些真正带来新东西的项目。我举了一些例子: * 隐私 * 应用专用的效率优化 * 超低延迟 当然,这个列表肯定远远不完整。 我相信的第二个重要观点是:关于“与以太坊的连接”,氛围(vibes)必须与实质(substance)相匹配。 我个人其实很喜欢很多被称为“应用链(app chains)”的东西。例如,我认为预测市场的最优架构,很可能是这样的: * 市场的发行和结算在 L1 上完成 * 用户账户在 L1 上 * 但交易发生在某个 based rollup 或类似 L2 的系统上 * 执行层通过读取 L1 来验证签名和市场状态 我喜欢那种与 L1 的深度连接是第一等公民,而不是事后补丁的架构。而不是那种: “我们基本上是一条独立的链,不过哦对了,我们有个桥;好吧那我们再安排 1–2 个开发者把它做到 stage 1,这样 l2beat 才会给我们打个绿勾,Vitalik 才会喜欢我们。” 而“应用链”的另一个极端版本同样是合理的。例如:你说服某个政府登记系统、社交媒体平台或游戏系统,把它数据库的 Merkle root 上链,并使用 STARK 来证明: * 每一次更新都是被授权的 * 被正确签名的 * 并且按照一个事先承诺好的算法执行 这种做法在我看来,最符合“机构级 L2(institutional L2s)”的逻辑。 显然,这并不是以太坊: * 它不是可信中立的 * 也不是无需信任的 运营方始终可以说:“我们现在切换到另一套规则版本。” 但它能实现可验证的算法透明性——这是我们很多人都希望在政府、社交媒体算法等领域看到的特性;而且它也可能开启一些原本不可能存在的经济活动。 我认为: 如果你属于第一种情况,那么称自己为以太坊应用是完全合理、而且很棒的: * 在技术上离不开以太坊 * 最大化与其他以太坊应用的互操作性和可组合性 如果你属于第二种情况,那么你并不是以太坊,但你: 为人类带来了更多算法透明性和更小的信任假设,追求的是相似的愿景 根据具体实现细节,很可能与以太坊形成协同关系 所以你应该直接、坦诚地这样说。 总结来说:做一些真正给桌面带来新东西的事情。 氛围要与实质匹配——你在公众形象中宣称自己与以太坊的连接程度,应该真实反映你在现实中与以太坊的实际连接程度。 Have been following reactions to what I said about L2s about 1.5 days ago. One important thing that I believe is: "make yet another EVM chain and add an optimistic bridge to Ethereum with a 1 week delay" is to infra what forking Compound is to governance - something we've done far too much for far too long, because we got comfortable, and which has sapped our imagination and put us in a dead end. If you make an EVM chain *without* an optimistic bridge to Ethereum (aka an alt L1), that's even worse. We don't friggin need more copypasta EVM chains, and we definitely don't need even more L1s. L1 is scaling and is going to bring lots of EVM blockspace - not infinite (AIs in particular will need both more blockspace and lower latency than even a greatly scaled L1 can offer), but lots. Build something that brings something new to the table. I gave a few examples: privacy, app-specific efficiency, ultra-low latency, but my list is surely very incomplete. A second important thing that I believe is: regarding "connection to Ethereum", vibes need to match substance. I personally am a fan of many of the things that can be called "app chains". For example I think there's a large chance that the optimal architecture for prediction markets is something like: the market gets issued and resolved on L1, user accounts are on L1, but trading happens on some based rollup or other L2-like system, where the execution reads the L1 to verify signatures and markets. I like architectures where deep connection to L1 is first-class, and not an afterthought ("we're pretty much a separate chain, but oh yeah, we have a bridge, and ok fine let's put 1-2 devs to get it to stage 1 so the l2beat people will put a green checkmark on it so vitalik likes us"). The other extreme of "app chain", eg. the version where you convince some government registry, or social media platform, or gaming thing, to start putting merkle roots of its database, with STARKs that prove every update was authorized and signed and executed according to a pre-committed algorithm, onchain, is also reasonable - this is what makes the most sense to me in terms of "institutional L2s". It's obviously not Ethereum, not credibly neutral and not trustless - the operator can always just choose to say "we're switching to a different version with different rules now". But it would enable verifiable algorithmic transparency, a property that many of us would love to see in government, social media algorithms or wherever else, and it may enable economic activity that would otherwise not be possible. I think if you're the first thing, it's valid and great to call yourself an Ethereum application - it can't survive without Ethereum even technologically, it maximizes interoperability and composability with other Ethereum applications. If you're the second thing, then you're not Ethereum, but you are (i) bringing humanity more algorithmic transparency and trust minimization, so you're pursuing a similar vision, and (ii) depending on details probably synergistic with Ethereum. So you should just say those things directly! Basically: 1. Do something that brings something actually new to the table. 2. Vibes should match substance - the degree of connection to Ethereum in your public image should reflect the degree of connection to Ethereum that your thing has in reality.Vitalik Buterin · 2026/02/05
- 在 X(Twitter)上可以轻松直接调用 @grok,可能是继「社区注释(Community Notes)」之后,对这个平台提升“对真相友好度”最重要的一件事。 关键在于:你无法提前知道 grok 会如何回应。 我已经看到很多次这样的情况:有人在召唤 grok 时,本来指望它能替自己那些疯狂的政治观点背书,结果 grok 出现后,直接把他们的立场“掀地毯”式拆穿了。 (意思是:反而当场打脸。) The easy ability to call @grok on twitter is probably the biggest thing after community notes that has been positive for the truth-friendliness of this platform. The fact that you don't see ahead of time how grok will respond is key here - I've seen many situations where someone calls on grok expecting their crazy political belief to be confirmed and grok comes along and rugs them.Vitalik Buterin · 2025/12/26