企业官网建设流程全解析

zcashd 平台支持体系详解：三级分层、保证级别与构建生态

【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash

zcashd（Zcash 共识节点实现）将不同平台（构建目标与操作系统）的支持划分为三个层级，分别对应"保证可用"、"保证可构建"与"代码库中存在但无任何保证"三种承诺。本文以官方《The zcashd Book》中的 Platform Support 文档为主体骨架，结合仓库内的 Platform Tier Policy、CI 工作流与跨平台构建基础设施，完整梳理各级平台的准入标准、当前状态、End of Support 规则以及背后的工程实现，帮助用户在选型部署环境、参与平台维护时做出有依据的决策。

一、平台支持三级体系：承诺强度从强到弱

zcashd官方文档将平台支持组织为三个层级，每一级都对应一组不同的保证，该模型借鉴了 Rust Target Tier Policy 的思路。三级承诺的强度递进关系如下：

三个层级的保证逐级累加：每个层级都继承上一层级的所有要求，除非被更强的要求覆盖。也就是说，Tier 1 平台必须同时满足 Tier 2 与 Tier 3 的全部条件。

从工程维护的角度理解这套体系：

• Tier 1面向 Zcash 生态中拥有大量实际生产用户的平台，ECC 对其投入最高强度的 CI 保障；
• Tier 2面向"社区确实需要、且有一支指定的维护者团队愿意持续跟进"的平台，ECC 承担"不让它坏掉"的责任，但不保证其测试全绿；
• Tier 3的门槛最低，主要约束是"不得干扰其他 Zcash 开发"，官方不提供任何构建或测试保证。

需要特别说明的是：层级只约束当前开发分支与未来发布版本，一个平台的升级或降级不会影响已经存在的稳定发布版本；平台层级的可用性也不是该平台未来保持层级的硬性稳定性承诺（见 platform-tier-policy.md）。

二、Tier 1：保证可用的平台

Tier 1 platforms can be thought of as "guaranteed to work". ECC builds official binary releases for each tier 1 platform, and automated testing ensures that each tier 1 platform builds and passes tests after each change.

Tier 1 平台由 ECC（Electric Coin Company）构建官方二进制发布版，并且每当代码库发生变更，自动化 CI 都会确保该平台既能构建成功，也能通过测试。这是 Zcash 官方对用户做出的最高级别承诺。

当前 Tier 1 平台（截至本仓库文档状态）：

| target | OS | End of Support | | ------ | -- | -------------- | |x86_64-pc-linux-gnu| Debian 12 | June 2028 | | | Ubuntu 22.04 | April 2027 |

End of Support 的含义

"End of Support"（支持终止日期）是该平台从 Tier 1 移除的最晚已知日期，该日期可能会发生变化。它并非某个软件的版本截止日期，而是平台支持层的"退出倒计时"：在到达该日期之前，ECC 仍承诺该平台保持在 Tier 1 的完整保证水平。

需要留意的是，End of Support 日期会受网络解算力（solution power）变化影响——这与 Release Support 中"End of Support 日期为估算值、可能因网络解算力变化而偏移"的说明一致。

三、Tier 2：保证可构建的平台

Tier 2 platforms can be thought of as "guaranteed to build". ECC builds official binary releases for each tier 2 platform, and automated builds ensure that each tier 2 platform builds after each change. Automated tests are not always run so it's not guaranteed to produce a working build, but tier 2 platforms often work to quite a good degree, and patches are always welcome!

Tier 2 的承诺是"保证能构建"：ECC 为每个 Tier 2 平台构建官方二进制发布版，自动化构建确保每次代码变更后该平台至少能编译通过。但自动化测试并不总是运行，因此不保证构建产物一定能正常工作。在实践中，Tier 2 平台通常工作得相当好——并且补丁永远受欢迎（patches are always welcome）。

当前 Tier 2 平台：

| target | OS | End of Support | | ------ | -- | -------------- | | N/A | | |

目前仓库中没有任何 Tier 2 平台，表格为 N/A。这意味着在x86_64-pc-linux-gnu（Debian/Ubuntu）之外，目前不存在"保证能构建但未保证测试通过"的中间层级平台——其他平台要么进入最高保证的 Tier 1，要么就落在无保证的 Tier 3。

四、Tier 3：代码库支持但无任何保证的平台

Tier 3 platforms are those for which thezcashdcodebase has support, but ECC does not require builds or tests to pass, so these may or may not work. Official builds are not available.

Tier 3 平台意味着zcashd代码库中存在对该平台的支持（构建目标、条件编译分支、工具链适配等），但 ECC不要求构建或测试通过——它们可能工作，也可能不工作，且不提供官方构建。

当前 Tier 3 平台：

| target | OS | notes | | ------ | -- | ----- | |x86_64-pc-linux-gnu| Arch | | | | Ubuntu 24.04 | | |x86_64-unknown-freebsd| FreeBSD | | |x86_64-w64-mingw32| Windows | 64-bit MinGW | |x86_64-apple-darwin16| macOS 10.14+ | | |aarch64-linux-gnu| ARM64 Linux | |

解读这张表时应注意两点：

1. 同一 target 可横跨多个层级。例如x86_64-pc-linux-gnu同时出现在 Tier 1（Debian 12、Ubuntu 22.04）与 Tier 3（Arch、Ubuntu 24.04）——层级的划分粒度是target 与具体操作系统发行版的组合，而非仅 target 本身。Debian 12 / Ubuntu 22.04 获得最高保证，而 Arch Linux 与 Ubuntu 24.04 则只处于"代码库中存在支持"的状态。
2. Tier 3 不设 End of Support 列，因为官方不对其做支持承诺，自然也没有"支持终止"一说。

五、平台层级策略与准入标准

Platform Tier Policy 是支撑上述表格的完整政策文档。它明确了每个层级"新增平台"所需满足的要求，并规定：Tier 3 的准入门槛最低，核心是避免干扰其他 Zcash 开发；Tier 2 与 Tier 1 则会给 Zcash 开发者整体带来持续维护负担，因此需要平台维护者付出相应且持续的投入，以证明其价值并最小化对 Zcash 开发主线的干扰。

政策文档采用 IETF RFC 2119 的 MUST / SHOULD / MAY 术语体系，同时明确：这些标准并不能取代评审者的人为判断，平台及其补丁必须符合要求的"精神"，由批准评审者（ECC 核心团队）依据工作质量与平台适配性自行裁量；该政策不构成任何有约束力的协议或禁止反言。

Tier 3 的准入要求

任何新增 Tier 3 平台必须经过 ECC 核心团队成员依据以下要求评审批准：

• 必须提供面向 Zcash 社区的构建文档，尽可能说明如何为该平台构建（优先交叉编译）；若平台支持运行二进制或运行测试（即使不通过），文档必须说明如何运行（优先模拟器，必要时专用硬件）；
• 不得给 PR 作者或其他社区开发者增加维护负担：不得基于 Tier 3 平台在 PR 上发布（自动或手动）跑题或建议阻塞的评论，不得向 PR 参与者发送未经其同意的自动通知（包括 @ 提及）；
• 不得破坏任何现有 Tier 2 / Tier 1 平台，未经 ECC 核心团队批准不得故意破坏其他 Tier 3 平台。

若 Tier 3 平台不再满足上述要求、长期无活动且久未构建、或移除它能提升代码库质量，ECC可以发起 PR 将其移除。

Tier 2 的准入要求

Tier 2 要求由 ECC 核心团队评审批准，且ECC 基础设施团队必须批准平台接入 CI 及其 CI 相关要求。在 Tier 3 全部要求的基础上，Tier 2 还需满足：

• 必须对除其推动者之外的人有价值（可以是小众平台，但绝不能仅服务于封闭群体）；
• 必须有一支指定的开发者团队（平台维护者）支持它，且无需付费支持合同；
• 不得给不相关的 Zcash 开发者带来过度负担：开发者不应随意破坏 Tier 2 平台，但也不被期望成为每个 Tier 2 平台的专家或提供平台专属实现；
• 必须在 CI 中可靠构建ECC CI 视为强制性的全部组件。

满足不了这些要求时，Tier 2 平台可以被降级或移除。

Tier 1 的准入要求

Tier 1 是最高标准，在 Tier 2 全部要求之上还需满足：

• 必须在 Zcash 社区中拥有大量、广泛的实际兴趣，且必须服务于多个组织或项目中多个 Zcash 生产用户的持续需求（该要求具有主观性；平台过时或不再满足时可以被降级或移除）；
• 必须在 CI 中可靠构建并通过所有测试（ECC CI 视为强制性的全部组件）；
• 构建与运行测试套件的耗时不得显著长于其他平台，且不应显著提高 CI 基础设施的维护负担；
• 不得有"必须使用签名/验证/已批准二进制"的硬性要求：开发者必须能在自己控制的系统上构建、运行和测试该平台的二进制（可启用合适的"开发者模式"，但不得要求支付额外费用或签署苛刻的法律协议）。

由此可见，Tier 1 的"保证可用"承诺背后是一整套关于社区价值、CI 可靠性与成本、二进制分发自由度的硬性约束——这也解释了为什么当前只有 Debian/Ubuntu（x86_64-pc-linux-gnu）两个发行版组合达到 Tier 1。

六、从文档到实现：CI 中的层级落地

平台支持表并非停留在纸面，而是直接映射到仓库的持续集成配置中。在 .github/workflows/ci.yml 的 CI 矩阵定义里，每个平台条目都显式标注了tier字段，与文档表格一一对应：

• Tier 1：Debian-bookworm（Debian Bookworm，container: electriccoinco/debian-helper:bookworm）与ubuntu-22.04，host: x86_64-pc-linux-gnu；
• Tier 3：ubuntu-24.04（x86_64-pc-linux-gnu）、mingw32（Windows 64-bit MinGW，host: x86_64-w64-mingw32）、aarch64-linux（ARM64 Linux，host: aarch64-linux-gnu）；
• macOS 的 CI 条目（macos-12，host: x86_64-apple-darwin）当前处于注释掉的状态，与 macOS 处于 Tier 3 无保证的定位一致。

CI 配置还揭示了层级在测试强度上的具体差异（见 ci.yml 中的注释说明）：

• 只能在与平台兼容的 runner 上运行测试，交叉编译平台（cross-compiled）被排除在测试矩阵之外；
• 部分测试当前在 Windows 平台无法工作，因此存在一个 Unix 测试子集；
• RPC 测试只在 Tier 1 平台上运行，以节省成本——这是"Tier 1 保证测试通过，Tier 2/3 不保证"这一承诺在基础设施层面的直接体现。

这些细节印证了文档中的承诺结构：Tier 1 平台的"测试全绿"是通过真实 CI 流水线持续保障的，而 Tier 3 平台只要求"不被故意弄坏"。

七、跨平台构建基础设施：depends 与 Gitian

zcashd的平台支持能力由仓库内两套基础设施承载：

depends/ 交叉编译目标

depends/hosts/ 目录为各平台定义了宿主（host）工具链：

• linux.mk 定义了i686_linux_CC/x86_64_linux_CC等 32/64 位 Linux 工具链（-m32/-m64），交叉编译时通过-idirafter /usr/$(host)/include引入目标系统头文件；
• mingw32.mk 使用x86_64-w64-mingw32-clang系列工具链构建 64 位 Windows 二进制——这与文档中 Tier 3 的x86_64-w64-mingw32（Windows，64-bit MinGW）完全对应；
• darwin.mk 定义OSX_MIN_VERSION=10.14（与文档中 macOS "10.14+" 的标注吻合），通过 clang 的-target $(host)、--sysroot $(OSX_SDK)实现 macOS 交叉构建。

Gitian 可复现构建

contrib/gitian-descriptors/ 下提供了gitian-linux.yml、gitian-osx.yml、gitian-win.yml等描述文件，用于在隔离环境中可复现地构建各平台发布包。例如 gitian-linux 脚本以x86_64-linux-gnu为宿主构建，并产出zcash-*-linux64.tar.gz/-linux64-debug.tar.gz发布归档。这套基础设施是"ECC 为 Tier 1/Tier 2 平台构建官方二进制发布"这一承诺的技术支撑。

官方支持范围的说明

仓库根 README.md 明确写道："Currently, Zcash is only officially supported on Debian and Ubuntu"（当前 Zcash 仅在 Debian 和 Ubuntu 上得到官方支持），并给出通用构建命令：

./zcutil/build.sh -j$(nproc)

这恰好与平台支持表中 Tier 1 仅包含 Debian 12 与 Ubuntu 22.04 两个发行版的事实相互印证："官方支持"在实践中的含义就是 Tier 1。其他平台（Arch、FreeBSD、Windows、macOS、ARM64 Linux）虽然代码库中有支持且部分有 CI 条目，但用户需要自行承担构建与运行的一切风险。

八、平台选择、版本生命周期与迁移建议

与版本支持的生命周期联动

平台支持并非孤立存在，它与zcashd的版本生命周期深度绑定。根据 Release Support 与 End of Life 文档，zcashd每个版本约每六周发布一次，每个版本一般支持 16 周，并设有End-of-Support halt（支持终止停机高度）：当 Zcash 链到达该高度时，节点会自动关闭且拒绝重启。因此，选择平台时不仅要看平台的 Tier，还要确认所用zcashd版本仍处于支持窗口内。

需要特别提醒的是：zcashd本身已进入弃用（deprecated）流程，不支持 NU6.3；其 6.20.0 的 End-of-Support halt（区块高度 3417100，2026-07-18 到达）已触发，所有zcashd6.20.0 节点均已停机。官方文档建议用户关注 End of Life 页面了解完整时间线与向 Zebra、Zallet 的迁移指引——在zcashd已进入生命周期末期的背景下，平台支持表更多是面向仍在使用zcashd分支的存量用户与下游项目。

实践建议

基于文档与仓库现状，可以给出如下选型参考：

• 生产节点：选择 Tier 1 平台（Debian 12 或 Ubuntu 22.04，targetx86_64-pc-linux-gnu），可获得官方二进制发布、构建与测试全保证，并在各自的 End of Support（分别为 2028 年 6 月与 2027 年 4 月）前保持 Tier 1 待遇；
• 愿意自行承担风险的构建：Tier 3 平台（如 Ubuntu 24.04、Arch、FreeBSD、Windows/MinGW、macOS 10.14+、ARM64 Linux）可以尝试从源码构建，但应预期可能遇到问题——文档明确表示"patches are always welcome"，遇到问题可向社区提交修复补丁（Tier 3 的约束是补丁不得破坏更高层级平台）；
• 评估维护投入：若你的团队希望将某个平台提升至 Tier 2，需按政策准备一支指定的平台维护团队、接入 ECC 基础设施团队认可的 CI，并持续承担构建保障义务。

结语

zcashd的平台支持体系是一份"承诺分级、工程落地、政策护航"的完整方案：Tier 1（Debian 12 / Ubuntu 22.04）通过 CI 构建与测试双重保障实现"保证可用"，Tier 2 目前空缺，Tier 3 覆盖 FreeBSD、Windows、macOS、ARM64 等广泛目标但无任何官方保证。这一体系与 Platform Tier Policy 的准入标准、.github/workflows/ci.yml 的分层 CI 矩阵、depends/hosts/ 的交叉编译工具链以及 Gitian 可复现构建基础设施相互印证，共同构成了用户选择部署平台与社区贡献者维护平台时的事实依据。结合zcashd已进入弃用流程的现实，建议用户在参考本表的同时密切关注 End of Life 的迁移指引。

【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash