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 仓库的比特币时间戳