在不共享源代码的情况下验证代码时间戳
验证是密码学声明转化为证据的时刻。你可以为每一次提交打上时间戳，但如果事后无法在不交出源代码的情况下验证该时间戳，那么这个系统恰恰在你最需要它的时候失效了。Timestamp GIT 是一个托管型 SaaS 和 GitHub 应用，它通过 OpenTimestamps 协议将 Git 提交哈希锚定到比特币区块链上。任何持有回执的人都可以验证该证明，但回执中从不包含你的代码。
为什么验证对代码时间戳至关重要
一个时间戳的好坏，取决于它的验证能力。对于现有技术而言，你需要证明某个特定提交在某个特定日期之前就已存在。这个证明必须双向有效：它既要足够有力，能被法院或审计机构采信；又要足够私密，不会为了证明其存在而泄露商业机密。
核心理念是零知识验证：在不暴露内容的情况下证明存在性。Git 提交哈希是仓库状态的单向指纹。哈希本身无法被逆向还原为源代码。当这个哈希被锚定到比特币区块链上时，你就获得了一条公开、不可篡改的记录，证明该指纹在特定时间点已经存在。
如果你对这个概念还不熟悉，请阅读什么是软件代码的存在性证明？。本文聚焦于验证环节：证明长什么样、如何检查它，以及验证结果意味着什么。
Timestamp GIT 自动化了底层协议，因此你无需手动运行 OpenTimestamps 命令或管理比特币交易。你只需安装一次 GitHub 应用，连接一个仓库，之后每个提交都会在每晚被批量处理并锚定。验证则通过徽章、公开状态页面和基于浏览器的默克尔链查看器来完成。
时间戳证明长什么样
每个锚定日会在你的仓库中生成两类主要产物：
- 一个清单文件（
.txt），列出当天批次中包含的提交哈希。 - 一个
.ots回执文件，包含 OpenTimestamps 证明和比特币锚定数据。
这些文件会被推送到仓库中专用的时间戳分支，或推送到一个影子仓库中。它们包含提交哈希和锚定数据——不包含源代码、文件内容，也不包含超出证明所需的仓库元数据。
由于 .ots 回执是公开且自包含的，任何持有该文件的人都可以对照比特币区块链验证锚定。该证明不依赖于任何私有数据库。Timestamp GIT 提供了一个网页验证器，可以在你的浏览器本地执行默克尔链校验，因此你无需安装软件即可验证，也不会暴露你正在检查的是哪个仓库。
为了让验证结果可见，Timestamp GIT 支持在你的 README 中嵌入徽章。徽章链接到仓库的公开状态页面。对于私有仓库，状态 URL 包含加密的 HMAC，只有授权用户才能查看结果。徽章本身可以显示最新锚定的比特币区块、已盖章的提交总数，或综合摘要。
使用 Timestamp GIT 进行分步验证
验证流程是为那些不想学习底层协议的人设计的。以下是常规路径。
第 1 步：在你的仓库上安装 Timestamp GIT GitHub 应用
这是一次性设置。在标准模式下，GitHub 应用会从受监控的源仓库读取 HEAD 提交哈希。它需要对源仓库的只读访问权限——因为 GitHub 权限体系不提供仅提交哈希级别的访问——以及对目标仓库的读写权限，证明分支将写入该目标仓库。在企业零知识模式下，一个简短的 GitHub Action 在你的基础设施上运行，仅将提交哈希推送到 Timestamp GIT API。在该模式下，源代码永远不会离开你的环境。
第 2 步：等待每晚锚定
提交哈希会被自动检测。每晚，一个工作进程会将待处理的哈希分组，创建清单文件，构建默克尔树，使用公共 OTS 日历创建 OpenTimestamps 证明，并将默克尔根锚定到比特币区块链上。比特币确认通常在每晚批次之后大约需要三小时，因此今天提交的代码通常第二天就可以验证。
第 3 步：使用徽章或状态页面
对于公开仓库，访问状态页面：
https://timestampgit.dev/status/{user}/{repo}
这个公开仪表板会显示证明的存续时间、最早的锚定日期、每日规律性、比特币区块和交易数据，以及日历热力图。它还提供可下载的审计 CSV 和 PDF 证书报告的链接。
你也可以直接查询状态 API：
# 最新锚定的比特币区块信息
curl -s https://timestampgit.dev/api/statusLast/acme/webapp
# 已提交/已盖章的提交总数
curl -s https://timestampgit.dev/api/statusCount/acme/webapp
# 用于 Shields.io 徽章的综合摘要
curl -s https://timestampgit.dev/api/statusSummary/acme/webapp
将 acme/webapp 替换为你的 GitHub 用户名或组织名以及仓库名。对于私有仓库，经过身份验证的 GET /api/badgeLink/{user}/{repo} 端点会返回附加了加密 HMAC 的徽章 URL 和 Markdown 片段。
第 4 步：打开特定日期的验证页面
要查看详细的、逐步的默克尔链证明，请打开：
https://timestampgit.dev/verification/{user}/{repo}/{date}
该页面在你的浏览器本地运行验证计算。它展示了从你的提交哈希一直到锚定默克尔根和比特币区块的多级默克尔链。由于计算在本地进行，服务方无法看到你正在验证什么。
第 5 步：下载正式记录
你可以从状态页面或 API 下载：
- 完整历史的 CSV 审计台账：
GET /api/audit/{user}/{repo} - 特定日期的 PDF 证书：
GET /api/report/{user}/{repo}/{date}
这些对于法律或合规存档非常有用。PDF 证书为你提供了一份可读的记录，而 CSV 则提供了完整的审计追踪。
如果你需要底层的验证数据，端点 GET /api/verify/{user}/{repo}/{date} 会返回完整的默克尔链数据，供本地验证使用。
解读验证结果与边界情况
一次成功的验证只意味着一件事：该提交哈希被包含在一棵默克尔树中，而这棵树的根在特定时间被锚定到了特定的比特币区块中。一旦该区块得到确认，时间戳就不可篡改。任何一方——包括 Timestamp GIT——都无法更改或伪造它。
有几个边界情况需要了解。
待处理的锚定
提交刚完成时，证明尚不存在。Timestamp GIT 每晚批量处理并锚定哈希。比特币确认通常在每晚工作进程运行后大约需要三小时。在这段时间窗口内，状态页面可能会将该批次显示为待处理。一旦交易确认，证明即可立即验证。
私有仓库
对于私有仓库，公开的状态和验证 URL 并非开放访问。系统会附加一个特定于服务器实例的加密 HMAC。只有持有完整签名 URL 的授权用户才能查看状态或验证页面。这样既保护了仓库名称和提交元数据的私密性，又允许指定的审计人员检查证明。
独立于 Timestamp GIT 服务器
验证不要求 Timestamp GIT 保持在线。证明依赖于比特币区块链数据。如果你偏好硬核方式，可以下载 .ots 文件，并使用标准的 OpenTimestamps 验证工具对照比特币区块链进行验证。Timestamp GIT 的浏览器验证器就是同一校验的托管版本。
丢失 .ots 文件
.ots 回执和清单文件存储在专用的时间戳分支或影子仓库中。如果你丢失了本地副本，可以从该分支重新下载。证明可以从服务最初写入的同一个 Git 位置恢复。
不共享源代码的验证：零知识优势
关于代码时间戳最大的误解是，服务方必须看到你的代码才能证明它存在。Timestamp GIT 并非如此。
在标准模式下，GitHub 应用只读取 HEAD 提交哈希。它从不读取、复制或存储你的源代码。在企业零知识模式下，GitHub Action 在你的基础设施上运行，仅将哈希推送到 Timestamp GIT API。在该模式下，Timestamp GIT 不需要对源仓库的读取权限。这使得企业零知识模式适用于高度敏感的环境。
第三方——审计人员、对方律师或法院——可以在你不授予仓库访问权限的情况下验证时间戳。你提供 .ots 文件或签名验证 URL，他们就可以对照比特币区块链检查证明。他们看到的是密码学证据，而不是源代码。
关于两种部署模式的设置细节，请参阅使用 GitHub 应用自动化代码时间戳。
常见问题
我可以在不安装任何东西的情况下验证时间戳吗？
可以。Timestamp GIT 提供了一个基于网页的验证页面，你可以使用 .ots 文件或公开状态页面进行验证。所有计算都在你的浏览器本地完成，因此无需安装任何软件。
验证需要共享我的源代码吗？
不需要。验证只使用提交哈希和 .ots 回执，其中不包含任何源代码。零知识架构确保你的代码保持私密。
时间戳需要多久才能验证？
时间戳每晚锚定，比特币确认通常需要大约 3 小时。一旦确认，证明即可立即验证。
如果我丢失了 .ots 回执文件怎么办？
.ots 文件存储在仓库的专用分支或影子仓库中。你可以随时从那里重新下载。
结论
验证是密码学时间戳真正发挥作用的地方。一个你无法检查的证明不算是证明。Timestamp GIT 让验证路径变得切实可行：安装一次 GitHub 应用，让提交每晚自动锚定，然后使用徽章、状态页面和浏览器本地验证来证明你的代码何时存在——而无需共享源代码。
在 Timestamp GIT 设置你的第一个仓库。
相关文章
