Arbitrum在8月20日17时（UTC）为Arbitrum One和Nova激活ArbOS 61 Elara。此次升级包含Stylus合约容量扩展、费用与数据可用性接口改进，以及供其他Arbitrum链选择的协议功能。最容易引发误读的是“协议级合规控制”：Elara确实把特定地址限制能力纳入软件，但ArbitrumDAO的正式提案明确说明，该功能在One和Nova上保持关闭。本次升级不能被描述成Arbitrum主网开始普遍冻结或过滤用户交易。

ArbOS升级可理解为Arbitrum体系的协议级硬分叉。节点运营者需要运行支持Elara的Nitro版本，才能在激活后继续正常同步。官方节点通知要求One和Nova运营者提前升级至Nitro v3.11.3；已经使用相应版本的节点无需重复操作。对普通用户，升级过程通常由基础设施提供商完成，但交易所、RPC服务和应用团队仍需监控节点版本、交易执行和费用变化。

Elara实际改变了什么

一项明确变化是把Stylus应用的合约代码大小上限提高到96KB。Stylus允许开发者使用Rust等语言编写在Arbitrum上运行的智能合约。复杂应用可能因为代码体积受限而被迫拆分合约，增加调用、部署和审计难度；更高上限为大型库和更复杂逻辑提供空间。该调整仅适用于Stylus应用，没有修改Solidity合约遵循的核心EVM大小假设，以避免对以太坊兼容性、节点性能和开发工具造成额外偏差。

升级还涉及最低L2基础费的管理机制。正式提案允许在设定区间内调整One和Nova最低基础费，以便在防垃圾交易、用户成本和DAO收入之间寻找平衡。基础费过低会降低用户成本，却可能增加垃圾流量并压缩协议收入；过高又会削弱应用活跃度和资本效率。授权范围、期限和链上治理条件比“费用可以改”本身更重要，开发者应以最终执行参数和治理记录为准。

Elara也包含面向其他Arbitrum链的可选AltDA接口，让链更整洁地接入替代数据可用性层。One和Nova仍按既有架构结算到以太坊，并不因代码中出现接口就自动更换数据可用性方案。同样，可选的优先费收取和地址限制能力也不会因为软件升级而自动开启。协议软件“具备某功能”与某条链“治理决定启用该功能”是两个不同状态。

合规控制允许链所有者限制来自预先识别地址的链上活动，主要面向有特定监管需求的专用链。官方提案反复注明，One和Nova此次不启用它。这个区别关系到用户权利和去中心化判断：若忽略启用状态，只根据代码能力下结论，会把潜在配置误报为已经生效的政策。未来任何启用变化，都应当查看具体链的治理提案、执行交易和参数，而不是根据营销材料推断。

开发者、节点和用户应该检查什么

节点运营者首先要确认Nitro版本和同步高度，检查激活点前后是否出现分叉、重组或RPC异常。基础设施团队应准备回滚与故障切换方案，并验证归档节点、索引器、预言机和跨链服务没有因新版本产生兼容问题。版本号相同也不代表部署配置完全一致，容器镜像、启动参数和依赖服务都应纳入检查。

Stylus开发者可以评估96KB上限是否能减少不必要的合约拆分，但“允许更大”不等于“应该无限做大”。代码体积增加可能提高审计复杂度、部署成本和攻击面。团队仍应模块化设计、限制权限、覆盖边界测试，并确认所依赖的工具链已理解新限制。安全审计要以最终部署字节码为对象，而不能只复用旧版本报告。

应用和用户则应关注实际费用、确认时间和服务稳定性。基础费管理机制带来更灵活的调整空间，但短期体验取决于链上需求、排序器行为和应用自身收费。任何声称升级必然使手续费永久降低或协议收入立即增加的判断都过早。应观察激活后的真实区块数据，再评估费用分布与活动变化。

治理层面，Elara展示了一种模块化路线：同一软件版本可以为不同链提供可选能力，而每条链通过治理决定开启哪些功能。好处是专用链能满足不同业务和监管需求，风险是用户更难仅凭“使用Arbitrum技术”判断一条链的实际权限。钱包、浏览器和数据平台未来需要更清楚地展示链级配置，包括是否存在地址限制、谁可改费率、权限多久到期，以及变更是否经过链上治理。

这次升级的准确结论应当是：Arbitrum One与Nova采用了Elara的新协议版本，获得Stylus容量和若干基础设施改进；软件同时包含面向其他链的可选合规能力，但One与Nova没有启用。把代码、配置和治理三层分开，是理解模块化区块链升级、避免制造恐慌或夸大宣传的基本方法。

来源：ArbitrumDAO正式提案及Arbitrum Foundation公告，https://forum.arbitrum.foundation/t/constitutional-aip-arbos-61-elara/30601