Cardano 的新智能合约库超出最初目标

Cardano 的 ContractsLibrary 计划已准备好六个可复用的智能合约，超过了最初五个的目标。AlwaysTrue 的 Developer Experience 计划负责人 Robertino Martinez 在 X Space 讨论 去中心化 Cardano 核心开发 中披露了这一进展。

该库旨在为开发者提供可直接集成的智能合约组件，而无需从零构建常见功能。受 Ethereum 生态中 OpenZeppelin 方法的启发，项目结合了链上代码、交易构建工具、技术规格以及形式化验证。

这六个合约已进入最终的代码与规范审查阶段。Martinez 强调，它们尚未完成安全审计，不应部署到 Cardano 主网。

六个合约正迈向公开测试

ContractsLibrary 原本预计交付五个可复用的智能合约。根据 Martinez 的说法，开发团队已准备了六个，并在更广泛的社区测试前开始最终质量检查。

该计划聚焦于完整的、面向应用的组件，而非零散的编程函数。开发者可以配置现有合约，调整其源代码，或组合组件以满足不同的应用需求。

该库借鉴了 Cardano 生态中已建立的开发模式，包括 Anastasia Labs 的相关工作。

Martinez 还确认，高保障团队已启动形式化验证工作。其初期重点是各合约共享的性质，随后再验证各个实现。

区分开发完成与投产就绪仍然很重要。已准备好的六个合约并不意味着已有六个通过审计或形式化验证的合约可不受限制地使用。

受 OpenZeppelin 启发的 Cardano 开发栈

OpenZeppelin 已成为 Ethereum 与其他 EVM 生态中广泛使用的可复用智能合约组件资源。ContractsLibrary 旨在提供一个与之相当、适配 Cardano 扩展 UTxO 架构的开发资源。

每个实现都被设计为结合多个相互关联的要素。

链上组件使用 Aiken 来定义由 Cardano 账本强制执行的规则。链下交易构建器，包括对 MeshJS 和 Tx3 的支持，帮助应用构造与这些验证器交互所需的交易。

技术规格描述每个合约的预期行为，而测试与形式化验证则提供了额外手段来评估实现是否满足既定要求。

该项目还使用 Lean 4 对选定的合约性质进行机器检验的证明。

这种一体化结构解决了 Cardano 开发中的一个实际挑战，即构建去中心化应用通常需要协调智能合约验证与链下交易构造。

通过提供相互衔接的组件，ContractsLibrary 旨在减少重复的开发工作，让常见的合约模式更易集成到新应用中。

[NEWSBREAK]

安全审查仍是最后一道要求

ContractsLibrary 是更广泛的 Developer Experience 计划的一部分，该计划已在 Martinez 继续领导下从 Input Output 转移至 AlwaysTrue。

该计划还包括其他工具，如 cardano-init，可帮助开发者生成互联的 Cardano 开发环境。

对 ContractsLibrary 而言，近期优先事项是完成代码质量检查、让实现可用于测试，并持续推进形式化验证。

Martinez 建议开发者将初始发布视为测试机会，而非投产就绪的库。他还指出，随着 Cardano 的开发工具适应即将到来的协议变更，临近的 Dijkstra 硬分叉是需要保持谨慎的另一原因。

该项目区分了已为安全审计做好准备的合约与那些已完成所需审查并达到稳定状态的合约。

其公共代码库提供了代码与开发文档，但现有资料并不能证明六个合约都已作为稳定实现发布。

因此，Martinez 的更新确立了一个明确的开发里程碑，团队准备的合约数量比最初计划多一个。公开测试、单独的验证以及所需的安全审查仍是独立步骤，在完成这些之前，这些实现不能被视为投产就绪的组件。