验证代码时间戳，无需共享源代码
验证是密码学声明转化为证据的时刻。你可以为每一次提交打上时间戳，但如果你无法在事后验证该时间戳而不交出源代码，那么系统恰恰在你最需要它的时候失效了。Timestamp GIT 是一个托管型 SaaS 和 GitHub App，通过 OpenTimestamps 协议将 Git 提交哈希锚定到比特币区块链上。任何持有凭证的人都可以验证该证明，但凭证中从不包含你的代码。
为什么验证对代码时间戳至关重要
时间戳的价值取决于它的验证能力。对于现有技术，你需要证明某个特定提交在某个特定日期之前就已存在。这个证明必须双向有效：它必须足够有力，能被法院或审计机构认可；同时又必须足够私密，不会为了证明代码存在而泄露商业机密。
核心理念是零知识验证：在不暴露内容的前提下证明存在性。Git 提交哈希是仓库状态的单向指纹。哈希本身无法被逆向还原为源代码。当该哈希被锚定到比特币区块链上时，你就获得了一个公开、不可篡改的记录，证明该指纹在特定时间点已经存在。
如果你对这个概念还不熟悉，请阅读什么是软件代码的存在性证明？。本文聚焦于验证环节：证明长什么样、如何检查、结果意味着什么。
Timestamp GIT 自动化了底层协议，因此你无需手动运行 OpenTimestamps 命令或管理比特币交易。你只需安装一次 GitHub App，连接一个仓库，之后每个提交都会在夜间被批量处理并锚定。验证则通过徽章、公开状态页面和基于浏览器的默克尔链查看器完成。
时间戳证明长什么样
每个锚定日会在你的仓库中生成两个主要产物：
- 一个清单文件（
.txt），列出当天批次中包含的提交哈希。 - 一个
.ots凭证文件，包含 OpenTimestamps 证明和比特币锚定数据。
这些文件会被推送到仓库中专门的时间戳分支，或推送到一个影子仓库。它们包含提交哈希和锚定数据——不包含源代码、文件内容或超出证明所需的仓库元数据。
由于 .ots 凭证是公开且自包含的，任何持有该文件的人都可以对照比特币区块链验证锚定。该证明不依赖于私有数据库。Timestamp GIT 提供了一个网页验证器，在你的浏览器本地执行默克尔链检查，因此你无需安装软件即可验证，也不会暴露你正在检查哪个仓库。
为了让验证可见，Timestamp GIT 支持在 README 中嵌入徽章。徽章链接到仓库的公开状态页面。对于私有仓库，状态 URL 包含加密的 HMAC，只有授权用户才能查看结果。徽章本身可以显示最新锚定的比特币区块、已盖章的提交总数或综合摘要。
使用 Timestamp GIT 进行逐步验证
验证工作流是为不想学习底层协议的人设计的。以下是常规流程。
第 1 步：在你的仓库上安装 Timestamp GIT GitHub App
这是一次性设置。在标准模式下，GitHub App 读取受监控源仓库的 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 App 仅读取 HEAD 提交哈希。它从不读取、复制或存储你的源代码。在企业零知识模式下，GitHub Action 在你的基础设施上运行，仅将哈希推送到 Timestamp GIT API。在该模式下，Timestamp GIT 不需要对源仓库的读取权限。这使得企业零知识模式适用于高度敏感的环境。
第三方——审计人员、对方律师或法院——可以在你不授予仓库访问权限的情况下验证时间戳。你提供 .ots 文件或签名验证 URL，他们就可以对照比特币区块链检查证明。他们看到的是密码学证据，而非源代码。
关于两种部署模式的设置细节，请参阅使用 GitHub App 自动化代码时间戳。
常见问题
我可以在不安装任何东西的情况下验证时间戳吗？
可以。Timestamp GIT 提供了一个基于网页的验证页面，你可以使用 .ots 文件或公开状态页面。所有计算都在你的浏览器本地进行，因此无需安装任何软件。
验证需要共享我的源代码吗？
不需要。验证仅使用提交哈希和 .ots 凭证，其中不包含任何源代码。零知识架构确保你的代码保持私密。
时间戳需要多久才能验证？
时间戳在夜间锚定，比特币确认通常需要约 3 小时。一旦确认，证明立即可验证。
如果我丢失了 .ots 凭证文件怎么办？
.ots 文件存储在仓库的专用分支或影子仓库中。你可以随时从那里重新下载。
结论
验证是密码学时间戳真正发挥价值的环节。一个无法检查的证明不算是证明。Timestamp GIT 让验证路径变得切实可行：安装一次 GitHub App，让提交在夜间自动锚定，然后使用徽章、状态页面和本地浏览器验证来证明你的代码何时存在——全程无需共享源代码。
在 Timestamp GIT 设置你的第一个仓库。
相关文章
