一个代码仓库,一个瓶颈。如果你曾经交付过软件,你一定熟悉这个套路。卡尔达诺正在尝试一个不同的结局。
不再由单一公司推动核心更新,而是将核心协议工作交给多个独立团队,并设置治理护栏以保持一致性。对于一个以同行评审研究和谨慎发布而闻名的链来说,这是一个重大的文化转变。
那么,当编写节点、账本规则和工具的人不再同属一个屋檐下时,实际会发生什么变化?
编者注:在2026年第一季度至第二季度,我密切关注了卡尔达诺的代码仓库和治理论坛,同时与两个竞标钱包和账本工作的独立团队进行了交流。氛围从“等待IOG”转变为“哪个工作组拥有规范和测试框架”。发布说明和一致性套件比品牌更重要。一些提案请求花费的时间比竞标者预期的要长,但我采访的团队喜欢可预测的审查关卡。从市场结构的角度来看,交易所主要要求更清晰的升级日历和最低版本,这告诉我协调因素仍然是成败关键。——达内尔·惠特克
卡尔达诺的下一阶段关注的不仅是去中心化区块生产,还有基础协议决策和实现的去中心化。
历史上,Input Output Global(IOG)主导了大部分核心工程,而卡尔达诺基金会和EMURGO负责生态系统和企业级工作。现在,计划是将核心职责分散到在更清晰的治理标准下运作的独立团队中。
这一转变旨在用专业化团队的联盟取代单一供应商的效率,平衡冗余、同行评审和思想竞争。
两个支撑框架支持这一过渡。首先,名为CIP-1694的治理蓝图概述了链上治理在实践中的样貌,包括委托者、委托代表和宪法委员会的角色。该规范存在于卡尔达诺的CIP仓库中,并已成为社区向所谓伏尔泰时代迈进的试金石。
其次,Intersect——一个旨在管理卡尔达诺长期治理和发展的成员制组织——正在承担协调职责、资金流和工作组。卡尔达诺基金会继续从其非营利使命出发,推动标准、教育和网络健康指标。
卡尔达诺如何走到这一步:从IOG到多团队模式
卡尔达诺的基础层是多年研究先行开发的产物。这在可靠性上取得了回报,但也意味着一家公司承担了大部分运营负担。社区提案、聚会和治理实验积累了向更广泛阵营转变的压力。Intersect的成立旨在将这一阵营正式化,创建了介于社区情绪和实际代码变更之间的论坛和工作组。
治理基础工作
CIP-1694勾勒了社区、民选代表和宪法委员会如何提议和批准协议变更的机制。这不仅仅是一份白皮书;它是一组接口,规定了决策如何流入实施、审计和发布轨道。
组织与角色
IOG仍然重要,尤其是在研究和新颖协议工作方面。但长期方向是将更多核心仓库、组件和维护任务交给不受单一路线图约束的团队。Intersect的职责是协调、发布提案请求并确保满足标准。卡尔达诺基金会则专注于管理、文档和生态系统可靠性检查。
在工具方面,像Mithril这样的组件——卡尔达诺节点的快速引导和验证层——展示了独立团队如何在不直接触及共识的情况下改进功能。同样,Hydra——卡尔达诺的同构状态通道栈——在核心开发的同时演进,瞄准边缘的可扩展性。
谁做什么:拆分核心协议
当人们说“核心”时,通常指的是节点(网络、共识、账本)、编译器和语言(Plutus、Marlowe)、钱包栈以及发布流程。拆分这些职责必须谨慎进行,以免用户感受到接缝。
技术指导与所有权
设想一个技术指导职能,负责设定兼容性要求、测试标准和发布关卡,而实施团队则竞争或协作以满足这些要求。Intersect的工作组和委员会旨在形式化这一职能。
旧模型 vs 新模型
领域 – 旧模型(IOG主导) – 新兴模型(多团队)
节点与账本规则:主要由IOG工程和合并 – 多个团队实施;指导组批准接口和发布
智能合约栈:Plutus/Marlowe路线图集中 – 语言/运行时由领域团队拥有;向后兼容性检查点
测试与质量保证:内部管道、社区测试网 – 共享测试框架;针对审计和模糊测试的公开提案请求
资金与授权:核心公司内部预算 – 通过Intersect治理的提案请求、拨款和链上批准的授权
标准与文档:混合所有权,临时流程 – 基金会主导的标准,附带社区审查和版本化规范
治理轨道:提案、审查和资金
去中心化开发离不开轨道。轨道是想法变成代码,进而变成政策的路径。
变更可能如何流动:
一个想法被起草为卡尔达诺改进提案或工作组范围内的提案请求。
利益相关者反馈进入公共仓库和治理论坛,代表们根据CIP-1694角色发表意见。
Intersect协调独立审查,设定测试要求,并向合格团队征求投标。
资金通过预先定义的计划或与治理里程碑相关的链上决策分配。
实施公开进行;测试网启用实验性标志。
候选发布版本经过安全审查和向后兼容性检查。
治理确认发布,权益池运营商按预定节奏升级。
这并没有消除IOG的影响力;只是为其他团队通过高质量工作在共享标准下赢得影响力创造了空间。该结构在公开的CIP仓库和Intersect资料中可见。
从想法到主网:没有单一老板的交付
显而易见的担忧是混乱。多个团队、多个活动部件、没有单一老板可能导致僵局。卡尔达诺的答案是让发布管道变得乏味、可预测且经过审计。
测试网和发布轨道
卡尔达诺保持多个测试轨道处于活跃状态。Preview用于破坏性变更。Preprod用于接近主网的行为。专门用于治理试验的轨道已在触及主网之前用于演练链上流程。重点不在于标签,而在于每个变更必须在权益池运营商被要求升级之前经受住多个环境的考验。
安全网:Hydra和Mithril
Hydra为构建者提供了一种无需等待基础层升级即可扩展用户流的方式。这赢得了时间,并减少了为了满足吞吐量需求而将风险变更塞入节点的压力。
Mithril帮助节点快速引导并安全验证快照,这在发布变更且许多运营商需要从头同步时尤为重要。它也是一个离散子系统在独立路线图上演进,同时保持在网络范围安全假设内的例子。
两者结合,使得独立团队更容易在自己的领域内改进功能,而不会破坏共识的稳定性。
对构建者、交易所和用户的启示
对于开发者来说,多个核心团队可能意味着更频繁、更有针对性的发布。语言更新可能独立于网络调整,而工具缺口可以由响应提案请求的专业机构填补。
构建者
好处是边缘速度更快和规范更清晰。风险是碎片化。如果两个团队对接口的理解不同,你的去中心化应用可能在测试中运行良好,但在一个小补丁下就会崩溃。这就是标准、一致性测试和正式发布说明变得不可或缺的地方。
交易所和托管方
在操作上,你需要密切关注发布节奏和弃用时间表。随着更多团队交付,日历会变得更繁忙。预计卡尔达诺基金会在升级窗口和最低支持版本方面会有更强的沟通。
普通用户
大多数用户应该不会注意到太多变化,除了钱包和去中心化应用更新更频繁一些。更大的故事是韧性:如果一个团队遇到延迟,其他团队可以保持管道流动。
未来一年值得关注的里程碑
如果你在跟踪交接过程,以下是表明实际进展的实践标志。
里程碑 – 关注什么 – 为什么重要
宪法/委员会正式化:治理角色和否决/批准权力的清晰文档(根据CIP-1694) – 定义谁可以阻止或批准变更
独立提案请求授予:Intersect公布核心组件(如钱包API、账本规则)的中标者 – 证明资金与交付代码挂钩,而非仅仅是提案
仓库管理多样化:维护者文件显示关键仓库中更多非IOG所有权 – 表明代码路径的真正去中心化
协调的主网发布:多团队特性在一个可预测的升级中落地,无故障 – 验证治理和测试管道
安全审查节奏:在发布前定期发布第三方审计和模糊测试报告 – 防止去中心化削弱安全性
风险与可能出错的地方
接口漂移:两个团队以微妙不兼容的方式实现同一规范,导致去中心化应用行为异常。
治理僵局:提案在委员会和代表之间停滞,导致紧急修复延迟。
资金错配:关键维护工作在提案请求周期中输给花哨的功能。
安全回归:更多的合并和更快的节奏增加了攻击面,但没有匹配的审计深度。
运营商疲劳:权益池运营商面临更频繁的升级和不明确的最低版本,增加了链分裂事件的风险。
责任分散:当出现问题时,所有者不明确,拖慢了事件响应速度。
去中心化不是免费的。没有严格的规范、强大的测试和清晰的所有权,多团队开发可能会将单点故障变成许多小故障。
常见问题
IOG是否正在退出卡尔达诺?
不是。IOG仍然是关键的研究和工程贡献者。变化在于拓宽核心开发,让多个独立团队在共享标准下拥有栈的各个部分,而不是由单一供应商完成大部分工作。
什么是CIP-1694,它为什么重要?
CIP-1694是一个治理规范,概述了卡尔达诺利益相关者、代表和宪法委员会如何互动以批准协议变更。它是使多团队开发模式可行的政策层。
谁协调独立团队?
Intersect,一个成员制组织,被定位为协调工作组、发布提案请求并帮助协调发布。卡尔达诺基金会通过标准、文档和生态就绪性提供支持。
开发会变得更快还是更慢?
两者都可能发生。独立团队可以并行工作并加速特定功能,但治理和兼容性检查可能增加最终发布的时间。随着时间的推移,通常会出现可预测的节奏。
这对去中心化应用开发者有何影响?
期待更清晰的规范,可能还有更频繁的SDK更新。代价是需跟上指导组或维护者提供的兼容性说明和测试向量。
权益池运营商和交易所应该关注什么?
关注官方发布说明、最低支持版本和升级窗口。随着更多团队交付,基金会和指导组的沟通变得更加重要。
这是卡尔达诺独有的吗?
不是。几个网络已从单一公司开发转向多团队或基金会主导的模式。卡尔达诺的特色在于大量使用正式规范和社区定义的角色,以保持共识变更的保守性。

资金费率
资金费率热力图
多空比
大户多空比
币安/欧易/火币大户多空比
Bitfinex杠杆多空比
账号安全
资讯收藏
自选币种