如何验证 Git 仓库的比特币时间戳
你的仓库里有一份 .ots 收据。现在有人——律师、审计师、做技术尽职调查的收购方——问出了唯一重要的问题：我们怎么知道这是真的？
这个问题正是密码学先期技术的全部意义所在。无法独立验证的时间戳只是数据库里的一条声明。任何人都能对照比特币区块链验证的时间戳才是证据。本文梳理了由 Timestamp GIT 锚定的仓库的验证路径，从 README 徽章一直到 Merkle 证明。
为什么验证对 Git 时间戳如此重要
Git 历史出奇地容易被质疑。提交日期由执行提交的机器设置，因此只需一个环境变量就能把日期改早。托管的历史存放在你无法控制的服务器上，自托管的历史则存放在拥有管理员权限的人可以改写的数据库中。在法律审计中，两者通常都会被当作自利之词而不予采信。
密码学锚定填补了这一空白——但前提是，证明能被既不信任你、也不信任供应商的第三方核验。这意味着两项要求：
- 验证不得要求信任 Timestamp GIT。 证明是一条以比特币区块为终点的 SHA-256 哈希链。任何人都可以用开源工具走完这条链。
- 验证不得要求暴露你的源代码。 Timestamp GIT 采用零知识模型运作：服务只接收提交哈希，绝不接收文件内容。除了哈希之外没有任何东西可供检查——而这正是审计师想要的，因为这意味着可以在不共享代码库的情况下共享证明。
正因如此，验证是一项密码学操作，而非代码审查。审计师、对方律师或收购公司的工程团队都能验证同一份收据并得出相同结论。
Timestamp GIT 证明长什么样
每晚锚定运行之后，每个被监控的仓库会得到三样产物：
- 每日清单（
.txt）——当天批量处理的提交哈希列表，每个仓库一个文件。 - 一个 Merkle 根——由该清单计算出的单个 SHA-256 哈希。所有单独的哈希都归并为一个值。
- 一份
.ots收据——将 Merkle 根绑定到某个特定比特币区块的 OpenTimestamps 证明。
这些产物会被推送回你仓库中一个专用的 timestamps 分支，或者推送到一个单独的影子仓库（如果你希望保持源仓库干净）。无论哪种方式，证明都与其所证实的代码一起进行版本管理，但位于各自的 ref 中——绝不会提交到你的工作分支。
有两点值得明确说明：
- 证明不包含源代码。只有提交哈希及其密码学归约结果。
- 证明不是专有格式。它是针对一笔比特币交易的标准 OpenTimestamps 收据，无论 Timestamp GIT 是否还存在，它都始终有效。
一旦收据文件进入你的仓库，你就拥有了验证所需的一切——剩下的只是工具问题。
使用 Timestamp GIT 工具的分步验证
第 1 步——找到证明
打开 timestamps 分支（或影子仓库），找到对应日期的清单以及匹配的 .ots 文件。如果你不想翻遍各个分支，仓库状态页会在浏览器中展示同样的信息：
https://timestampgit.dev/status/{user}/{repo}
第 2 步——查看公开状态页
状态页是最快的初步检查。它会显示：
- 证明的存续时长和最早的锚定日期
- 每日规律性（已锚定日期的日历热力图）
- 承载锚定的比特币区块和交易
- 审计 CSV 和 PDF 证书的下载链接
如需自动化检查，同样的数据也以 JSON 形式提供：
# Last anchored Bitcoin block
curl -s https://timestampgit.dev/api/statusLast/acme/payments-service
# Total number of stamped commits
curl -s https://timestampgit.dev/api/statusCount/acme/payments-service
# Combined summary (used by the Shields.io badges)
curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service
第 3 步——在浏览器中验证特定日期
如需按天验证，请使用密码学验证页面：
https://timestampgit.dev/verification/{user}/{repo}/{date}
该页面在你的浏览器本地执行完整的多层 Merkle 链验证。提交哈希、清单、Merkle 路径和比特币区块头都在你的机器上检查——页面不会上传你正在验证的内容。当仓库是私有的或受保密协议约束时，这一特性尤为重要：审计师可以确认证明，而供应商无从得知他们关心的是哪个日期。
第 4 步——获取审计账本或 PDF 证书
合规团队通常需要一份可以归档的产物。两者只需一次请求：
# Full audit ledger as CSV
curl -fsSL https://timestampgit.dev/api/audit/acme/payments-service -o audit.csv
# PDF certificate for one day
curl -fsSL https://timestampgit.dev/api/report/acme/payments-service/2026-09-14 -o certificate.pdf
第 5 步——可选：嵌入验证徽章
/connected/{user}/{repo} 处的徽章组件会提供实时预览和可直接粘贴到 README 的 Markdown 片段。把它放进去，任何人——客户、投资者、潜在收购方——都能点击进入公开验证视图：
<!-- Snippet copied from https://timestampgit.dev/connected/acme/payments-service -->
[](VERIFY_LINK)
上述每一步都运行在托管的 GitHub App 工作流上。你只需安装一次应用，验证就是一次页面加载或一次 HTTP 请求——无需命令行工具，无需手动处理协议，开发人员的机器上没有任何需要维护的东西。
解读验证结果与边缘情况
一次成功的验证告诉你一件范围很窄但很有力的事：该提交哈希在收据所引用的比特币区块时间戳之时或之前就已存在，并且 Merkle 证明将该特定哈希与该区块关联起来。由于比特币区块若不重做工作量证明就无法被改写，这个“在……之时或之前”的界限是绝对的。
有几种情况经常出现：
- 某日期没有证明。 通常意味着那天没有提交——清单由待处理的哈希构建，因此空的一天不会产生任何可锚定的内容。查看状态页上的热力图以确认。
- 待确认。 锚定是一个两阶段过程。每晚的 cron 工作进程批量处理哈希、构建 Merkle 树，并将根提交到公共 OpenTimestamps 日历；随后在比特币区块中确认需要几个小时——通常约三个小时。因此，午夜后不久写入的证明可能要到当天上午晚些时候才最终确定。
- 私有仓库。 访问私有仓库的状态页和验证页需要在 URL 后附加一个加密的 HMAC。该 HMAC 特定于服务器实例，因此链接无法在另一个部署上重放。
- 供应商独立性。 如果你根本不想使用托管验证器，可以下载
.ots文件，自行通过开源 OpenTimestamps 工具对照比特币区块链运行。这是更费劲的方式，也更慢，但它确实存在——而它的存在正是托管路径可信的原因。
在企业与自托管环境中验证
企业 ZK 模式。 一个 12 行的 GitHub Action 在你自己的基础设施上运行，只向 Timestamp GIT API 推送提交哈希。服务从不对源仓库拥有读取权限；你只需对接收证明的目标仓库拥有读写权限。验证方式不变——同样的 .ots 文件、同样的公开比特币数据、同样的基于浏览器的 Merkle 检查。
Docker 自托管。 对于气隙环境，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 并配置部署。验证完全在你的网络内部进行：.ots 文件、清单和本地验证器就是你所需的全部。
如需评估，可通过在 Docker 许可证页面提交请求表单（附上你的姓名、公司、电子邮件和可选电话号码）获取限时演示许可证；许可证文件可立即下载。
为合规团队自动化验证
手动验证对一次审计来说没问题。持续合规则希望把它放进流水线。REST API 可以满足这一点：
#!/usr/bin/env bash
set -euo pipefail
REPO="acme/payments-service"
BASE="https://timestampgit.dev/api"
# Merkle chain data for local verification of a specific day
curl -fsSL "$BASE/verify/$REPO/2026-09-14" -o "verify-2026-09-14.json"
# Monthly audit ledger
curl -fsSL "$BASE/audit/$REPO" -o "audit-$REPO.csv"
# PDF certificate per anchored day
curl -fsSL "$BASE/report/$REPO/2026-09-14" -o "certificate-2026-09-14.pdf"
对于仪表盘，轮询状态端点而非完整的验证负载：
# Feed /api/statusLast and /api/statusCount into your monitoring system
curl -fsSL "$BASE/statusLast/$REPO"
curl -fsSL "$BASE/statusCount/$REPO"
一个有用的模式是把过期的 statusLast 视为告警条件：如果对于有活跃提交的仓库，最后锚定的区块超过一天没有变化，说明流水线中某处需要关注。所有验证计算都在浏览器本地或你自己的脚本内部进行——没有任何敏感负载离开你的掌控。如果你还在搭建锚定这一侧，请参阅自动化 Git 时间戳：GitHub App 如何锚定每一次提交；本文刻意只讲之后发生的事。
常见问题
验证 Timestamp GIT 证明需要运行任何命令行工具吗？
不需要。Timestamp GIT 提供一个基于网页的验证页面，在你的浏览器本地执行所有密码学检查。如果你愿意，也可以下载 .ots 文件并使用标准 OpenTimestamps 工具，但托管服务无需使用任何 CLI。
我可以在不信任 Timestamp GIT 的情况下验证时间戳吗？
可以。证明仅依赖 SHA-256 哈希和比特币区块数据。你可以使用开源 OpenTimestamps 工具独立地对照比特币区块链验证 .ots 文件，从而确保供应商独立性。
时间戳需要多久才能变得可验证？ 在每晚的 cron 任务将 Merkle 根锚定到一笔比特币交易后，该交易通常需要约 3 小时才能在比特币区块中确认。一旦确认，证明即不可篡改且可验证。
我可以验证私有仓库的时间戳吗？ 可以，但访问私有仓库的状态页和验证页需要在 URL 后附加一个加密的 HMAC。这确保只有授权用户才能查看证明详情。
结语
验证正是时间戳从承诺变为证据的地方。这条链很短且可核查：提交哈希 → 每日清单 → Merkle 根 → 比特币区块。无论你是在状态页上确认、运行基于浏览器的 Merkle 验证，还是为归档拉取 CSV 账本，结论都建立在比特币数学之上，而非任何人的言辞之上——包括我们的。
在一个仓库上安装 GitHub App，让每晚的运行完成它的工作，然后在任何人要求你之前自己验证一个日期。这只需几分钟，却是“我们认为我们能证明它”和“这就是证明”之间的区别。
相关文章
