Cardano的62M ADA维护提案将基础设施变为国库测试

Michael Karg解释为什么Cardano维护不仅仅是后台工作

Cardano围绕IO & Ensurable Systems Cardano维护计划的治理辩论在2026年5月12日举行的新Cardano治理时间会议中获得了重要技术背景支持。在Cardano基金会的Nicolas Ceani主持的讨论中，Input Output Engineering的Cardano性能与追踪负责人Michael Karg解释了该提案的内容、为何需要超过62百万ADA以及为何维护不应被视为例行的后台工作。

Karg没有以营销代表的身份发言。他以技术团队领导的身份发言，该团队负责Cardano最隐形但最重要的基础设施层之一。他的团队负责Cardano节点的可观测性，包括日志记录、指标、可观测事件和系统级基准。这实际上意味着帮助测量协议更改、节点更改或Plutus执行预算调整对权益池运营商和其他网络参与者使用的实际资源的影响。

这一点很重要，因为该提案不仅是关于IO是否应该收到大规模的国库提款请求，它还涉及到谁来维护Cardano的核心基础设施、如何衡量网络安全、如何准备发布版本、如何管理技术债务以及Cardano如何随着时间的推移逐步向更强的节点多样性迈进。

该提案申请62,134,630 ADA，涵盖从2026年第三季度到2027年第一季度结束的九个月期间。Karg在讨论中澄清，这项计划不是为期12个月的请求，而是一个9个月的维护周期。

他的核心观点是，Cardano维护提案不同于引入明显新功能的提案。他将其描述为生态系统的“引擎室”中的工作，用户通常不会注意到这一部分的正常运转。当一切都运转良好时，这正是问题的政治敏感部分。Cardano治理并不是在为新的钱包、新的DeFi应用或新的用户界面功能进行投票，而是在为保持系统稳定以支持其他所有建构所需的工作进行投票。

讨论时，该提案仍远未获批准，但Karg指出许多代表通常会等到治理行动的最后几天才进行投票。这种投票模式使早期的情绪难以揣测，但它也增加了对大型技术提案在最终决定窗口关闭之前进行清晰解释的压力。

Cardano Blueprint和节点多样性扩大了维护辩论范畴

讨论的最重要部分不仅仅是减少维护可能会增加运营风险的警告。Karg展示了Cardano维护计划涵盖了一个更广泛的技术包，包括漏洞修复、架构、DevOps基础设施、测试网络操作、基准系统、灾难恢复协议、监控工具、发布支持、安全流程以及关键Cardano工具。

这一范围包括引导中继操作、测试环境（如Preview和PreProd）的维护、Haskell编译器支持、主网监控、全球内存池监控、开源支持以及Plutus解释器、DB Sync、Cardano CLI、Cardano API、护栏和宪法委员会身份脚本等工具上的工作。

其中一个最重要的话题是Cardano Blueprint。Karg将其描述为构成Cardano的技术蓝图，包括节点之间通信协议、字节级细节、加密功能以及独立于代码本身的规范。这不是为了记录而记录。蓝图很重要，因为它为其他团队在Rust、TypeScript或其他语言中构建自己的节点实现提供了更清晰的框架。

这使维护提案成为超越常规维护的内容。Cardano经常谈论去中心化治理、权益池操作和决策制定，但长期的实现多样性也是图景的一部分。Haskell节点今天仍然是参考实现，但一个更健康的生态系统不应该永远依赖一条代码路径、一个工程中心或一个组织。

Ensurable Systems的加入也在这一背景下进行。IO将在此周期内领导交付，但Ensurable Systems被列为具有Cardano领域知识和经验的交付伙伴，因为它的创始人此前曾在IO工作。Karg将此与去中心化的管理联系起来，这意味着Cardano维护在长期内不应该仅由一个组织负责。

一个最具技术趣味的细节是Haskell编译器支持。Karg表示Cardano节点可能是现有最复杂的Haskell应用程序之一。因此，IO与Haskell编译器团队紧密合作，因为Cardano基准可以揭示代码生成问题，而标准编译器基准套件可能无法涵盖这些问题，仅仅因为Cardano代码库非常庞大和复杂。

这一细节显示维护不仅仅是国库表中的一个行政项目。对于Cardano而言，维护包括性能纪律、理解系统限制、与基础开发工具进行合作，并为未来的升级（如Leios、Hydra、多资产国库功能和其他取决于稳定核心节点的变更）做准备。

代表们正在根据证据而不是成本进行投票

这项提案的最大挑战不仅仅是维护是否重要。挑战是信任。超过62百万ADA的请求规模很大，而Cardano国库目前正面临多项并行提款提案。在这种环境中，代表们有权要求预算、交付成果和可衡量结果之间的清晰关联。

Karg指出公开的基准报告和Cardano更新是透明的一部分。基准报告比较以前和新的节点版本，跟踪资源使用、区块生成、区块传播和区块采纳，并通常与发布说明相关联。对权益池运营者和技术代表而言，这并不是装饰。这是维护工作通过可衡量的网络性能变得可见的方式之一。

这是该提案的一个强有力论点，但它并不能消除所有的担忧。主持人提出了关于九个工作流中有多少人参与工作，以及代表们如何理解团队分配、全职员工的容量和优先级的问题。Karg回答说交付成果跨越多个团队和工程师，IO使用历史数据来估算努力和时间，并且该提案以结果为导向。换句话说，IO正在对请求金额内的结果负责。

这个回答在技术上是合理的，但在公众治理沟通方面并不完美。想要更简单预算分解、更清晰的全职员工分布以及按类别更精确的成本结构的代表可能会继续提出问题。这并不意味着该提案薄弱，但它表明其沟通必须非常精准。对于如此规模的请求，仅仅说维护重要是不够的。社区需要看到可以验证的东西，了解进度将在哪里可见，以及国库资金如何成为运营产出。

还有一个优先级问题。如果Cardano同时资助维护、Leios和其他技术提案，则相同的组织和工程人才可能会涉及多个工作流。Karg解释说，IO通过每周和每月评估、相互依赖性以及按项目的独立预算跟踪来管理优先级。这表明内部流程存在，但它也证实了Cardano治理现在进入了一个阶段，即技术提案不能孤立地进行判断。

这就是为什么投票并不简单。拒绝一个大规模国库请求可能看起来像是财政纪律。批准它可能看起来像是负责任的基础设施资助。双方都有论据，但浅层版本的辩论错过了重点。真正的问题不是社区是否喜欢这个数字的规模。真正的问题是Cardano是否能够区分看起来昂贵的成本和只有在失踪时才变得重要的基础设施。

因此，这项提案应该以证据而不是炒作进行辩护。如果IO和Ensurable Systems希望赢得代表的信任，他们最强的论据将不是对问题的恐惧，而是请求金额、公开交付成果、基准纪律、蓝图文件和长期实施去中心化之间的清晰联系。Cardano治理不仅在决定是否支付维护费用。它正在决定是否能够负责任地资助一项技术纪律，这一纪律决定了其应用、权益池和未来升级之下基础是否会足够坚实。