OpenTimestamps 替代方案：托管式 Git 时间戳

你已经接受了这个前提：你希望将 Git 提交锚定在比特币上，以便你的仓库在某个特定日期的特定状态可以被证明存在。这一点无需争论。

真正的购买决策在于谁来运行这条流水线。

OpenTimestamps 协议是大多数此类系统所基于的标准，它确实很优秀——开放、供应商中立、可对照比特币本身进行验证。但协议是工具箱，不是产品。从“协议存在”到“我的提交每晚都被打上时间戳，而且我的合规负责人可以下载 PDF 证书”，中间还有大量工作要做。本文比较了 2026 年 Git 时间戳的现实可行方案，以便你决定这些工作应该由谁承担：是你团队的负担，还是一个安装一次即可的 GitHub App。

购买决策：为什么要超越原生 OpenTimestamps？

OpenTimestamps 解决了困难的密码学问题：它利用公共日历服务器将一个哈希转换为锚定在比特币区块链上的存在性证明，因此你无需为每个时间戳支付交易费用。

它没有解决的问题：

• 提交检测。 协议根本不知道 Git 是什么。必须有人决定哪些提交需要被打上时间戳。
• 批量处理的经济性。 为每个提交单独生成证明是浪费的。实际部署会将每天的哈希批量处理成一棵 Merkle 树，只锚定根哈希。
• 密钥与证明存储。 .ots 收据很小，但它们必须存放在持久的地方，一个三年后律师还能找到的地方。
• 验证体验。 “下载一个文件并对照比特币检查”并不是大多数合规团队会采用的工作流程。
• 持续运营。 日历服务器的各种怪癖、升级路径，以及当晚间任务悄悄停止生成证明时由谁负责待命的问题。

这就是 DIY 的隐藏成本：不是密码学，而是围绕它的管道工程。选择在于：是继续运营一个协议，还是采用一个端到端自动化它的服务。Timestamp GIT 是本次比较中的托管选项——它将协议隐藏在 GitHub App 和夜间任务之后，因此没有任何开发者需要接触时间戳命令。

在比较之前，先说一句实话：是的，你确实可以用开放协议加一个 cron 任务手动实现所有这些。本文是将这条路径与替代方案进行比较；它不会手把手教你如何构建它。

全景概览：Git 时间戳有哪些可选方案？

你会遇到四种形态的解决方案。

1. 原生 OpenTimestamps 方案。 你安装客户端工具，自己编写提交收集脚本，管理日历交互，自行存储证明，并手动对照比特币进行验证。控制力最大，需要处理的面积也最大。它不是 Git 原生的，也不附带仪表盘、徽章或审计报告。

2. 带 API 的区块链时间戳平台。 它们提供一个 HTTP 端点，接受哈希并返回收据。比原生工具更好，但它们是通用的——它们为任何东西打时间戳，所以 Git 集成是你自己的问题。你仍然需要构建提交监听逻辑、批量处理和存储层。

3. 托管式 Git 时间戳服务。 这就是 Timestamp GIT 所属的类别：安装一个 GitHub App，选择仓库，每个提交都会被自动收集。每晚一个 worker 会批量处理当天的提交哈希，构建一棵 Merkle 树，并通过公共 OpenTimestamps 日历将根哈希锚定到比特币中。证明会回落到你自己的仓库中。

4. 自托管、授权部署。 托管式的便利不一定意味着使用别人的服务器。Timestamp GIT 以 Docker 镜像形式发布，你可以自行运行——这是适用于气隙环境和严格安全策略的相关选项。

选择标准：开发者和合规团队应该评估什么

当你比较各种选项时，底层协议的重要性不如其上的运营模式。六项标准承载了大部分决策：

• 设置工作量。 一键安装 GitHub App，还是安装工具、编写脚本并配置调度器。
• 自动化程度。 系统会自行发现新提交，还是必须由人记得去做？
• 安全与隐私。 服务能否在不读取你源代码的情况下完成工作？是否存在你的代码永不离开你基础设施的模式？
• 集成面。 Git 托管集成、README 徽章、REST 端点、CSV 审计账本、PDF 证书。
• 成本模型。 公共仓库的免费层、私有仓库透明的分级定价，以及当你需要主权时的自托管许可证。
• 可验证性与锁定。 第三方能否在无需你的供应商参与的情况下，使用标准工具和比特币区块数据验证你的证明？

最后一项标准是团队容易低估的。一个你无法独立验证的时间戳，只不过是一行带有出色营销的数据库记录。

并排对比：原生协议 vs. 托管服务

注意中间一列的模式：API 消除了密码学工作，但留下了 Git 工作。这往往是 DIY 项目停滞的地方——不是因为锚定很难，而是因为提交收集、批量处理和交付足够无聊，以至于被永久性地降低优先级。

结论：谁应该选择哪个选项？

独立开发者和开源维护者。 如果你喜欢这些管道工程，而且你的仓库本来就是公开的，那么原生协议是站得住脚的。但 Timestamp GIT 的免费层覆盖公共仓库，所以诚实的问题是：你的时间花在项目上是否比花在维护证明流水线上更有价值。至少，它消除了“我下个月会好好自动化这件事”的失败模式。

初创公司和代理机构。 走托管路线。在先技术论据不在乎你本可以给那些提交打时间戳——它们在乎的是你确实在争议发生前的几个月里持续地打了。一致性是一个产品特性，而夜间自动化实现它的效果远胜于良好的意愿。如果你是在付款纠纷中证明交付日期，请参阅用区块链证明保护代理机构代码交付物。

有严格安全策略的企业。 标准模式加上企业 ZK 路径，或 Docker 自托管许可证，能给你所需的控制，而无需自己重建协议。当源仓库不能被服务读取时，企业 ZK 模式就是你要选择的——一个 GitHub Action 从你自己的基础设施推送提交哈希。如果你担心的是专利暴露而非仓库权限，用于专利纠纷的 Git 提交时间戳证明涵盖了该场景。

简短版本：Timestamp GIT 不仅仅是运行协议的一个替代方案——它是你无需亲自运营的那个协议版本。

Timestamp GIT 作为托管替代方案如何运作

以下是面向开发者的完整工作流程。

1. 安装一次 GitHub App。 开发者机器上无需安装任何东西。该应用仅读取受监控仓库的 HEAD 提交哈希；你的源代码永远不会被读取、复制或存储。在标准模式下，该应用需要对源仓库至少具有只读访问权限（GitHub 的模型中没有“仅哈希”权限），并对目标仓库具有读写访问权限，证明就写入那里。

2. 提交被自动收集。 要么 GitHub App 通过 webhook 检测新提交，要么——在企业 ZK 模式下——一个 12 行的 GitHub Action 仅将提交哈希推送到 Timestamp GIT API。在 ZK 模式下，不需要对源仓库的读取权限，但你需要安装该 Action。待处理的哈希存放在内存键值存储中，等待批量处理。

3. 午夜 cron worker 锚定该批次。 每晚，worker 将所有待处理的哈希分组，按仓库构建清单 .txt 文件，构建一棵 Merkle 树，使用公共 OTS 日历创建 OpenTimestamps 证明，并将 Merkle 根锚定到比特币区块链中。比特币确认通常需要约三小时，因此证明会在批次运行后几小时出现。

4. 证明被交付到你的仓库中。 清单和 .ots 收据文件被推送回专用的 timestamps 分支或影子仓库。从那一刻起，时间戳就是不可变的——没有任何实体，包括 Timestamp GIT，能够更改或伪造它。

5. 你进行验证并发布。 可嵌入的 README 徽章显示验证状态并链接到公共验证页面。仓库状态仪表盘展示证明的持久性、最早的锚定日期、每日规律性、比特币区块和交易数据、日历热力图，以及可下载的 CSV 审计账本和 PDF 证书。验证本身在浏览器中针对 Merkle 链本地运行——我们这边不做任何计算，没人能看到你验证的内容。如果你想了解详细机制，请阅读如何验证 Git 仓库的比特币时间戳。

对于仪表盘之外的自动化，有公共端点：

curl https://timestampgit.dev/api/statusSummary/your-org/your-repo
curl https://timestampgit.dev/api/statusLast/your-org/your-repo
curl -O https://timestampgit.dev/api/audit/your-org/your-repo

私有仓库会在其 URL 后附加一个加密的 HMAC，特定于服务器实例，因此只有授权用户才能读取其状态。

自托管选项

为了最大安全性和气隙环境，Timestamp GIT 以 Docker 镜像形式提供。一个快速开始的 Docker Compose 设置如下所示：

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

应用可在 http://localhost:8080 访问。首次启动时，设置向导会引导你连接 GitHub App 并配置实例。通过在 Docker License 页面提交请求表单（附上你的姓名、公司、电子邮件和可选电话号码），可获得限时演示许可证；随后即可下载许可证文件。

常见问题

我需要运行任何 OpenTimestamps 命令吗？

不需要。Timestamp GIT 是一项托管服务。一旦你安装了 GitHub App，它会自动检测提交并每晚将它们锚定到比特币中。你永远不需要运行 CLI 工具或自己管理协议。

我可以在没有 Timestamp GIT 的情况下验证证明吗？

可以。.ots 收据文件和 Merkle 证明基于开放标准。你可以使用标准 OpenTimestamps 验证工具对照比特币区块链独立验证它们，或使用 Timestamp GIT 的本地浏览器验证，所有计算都在客户端进行。

如果 Timestamp GIT 倒闭了会怎样？

你的证明锚定在比特币区块链中，且与供应商无关。.ots 文件和 Merkle 证明可以使用开源工具离线验证。Timestamp GIT 不会锁定你；密码学证明仅依赖 SHA-256 和比特币区块数据。

我的源代码会被暴露吗？

不会。Timestamp GIT 遵循零知识原则。在标准模式下，GitHub App 仅读取提交哈希，而非源代码。在企业 ZK 模式下，一个 GitHub Action 从你的基础设施仅推送提交哈希，因此你的源代码永远不会离开你的环境。

结语

本次比较中的每个选项最终都到达同一个地方：比特币区块中的一个 SHA-256 哈希。不同之处在于，为了到达那里，你必须提供多少工程、运营纪律和机构记忆——以及结果是否是合规团队能够真正交给律师的东西。

如果你想要密码学保证而不想成为时间戳流水线的维护者，安装一次 GitHub App，让夜间 worker 完成其余工作。从公共仓库的免费层开始，看着证明落地，然后在准备好时将私有仓库迁移到 Pro Agency。你的提交已经有哈希了；它们不妨也有见证者。

相关文章

• 用区块链证明保护代理机构代码交付物
• 用于专利纠纷的 Git 提交时间戳证明
• 如何验证 Git 仓库的比特币时间戳