什么是软件代码的存在性证明？
对于开发者和合规团队来说，“存在性证明”并不是要证明所有权或作者身份。它只回答一个狭窄的问题：这段确切的代码是否在这个时间点存在过？ 在一个 Git 历史可以被改写、文件时间戳可以被修改、内部日志常常被视为自说自话的世界里，软件代码的存在性证明意味着将你工作的加密指纹锚定到一个不可篡改的公共账本中。
本文解释了存在性证明的含义、其底层工作原理，以及 Timestamp GIT 如何将其转化为零配置的 GitHub 工作流。
对于代码而言，“存在性证明”意味着什么？
软件代码的存在性证明，是指能够证明某段特定代码——更准确地说，是那段代码的加密哈希——在某个特定时间点已经存在。
最后这一点很重要。你不需要公开源代码，也不需要将其上传给第三方。相反，你只需创建仓库状态的一个单向指纹，并将该指纹记录在某个公开且防篡改的地方。
为了理解其中的区别：
- 存在性证明表明某个代码状态在某个日期已经存在。
- 作者身份证明表明是谁创建或提交了那段代码。
- 所有权证明是基于作者身份、雇佣协议、权利转让或其他证据得出的法律结论。
区块链锚定的时间戳并不能证明你写了那段代码。它证明的是那段代码在那个时刻已经存在。在许多争议中，这种区别已经足够了——因为如果你的实现早于他人的专利申请或主张存在，时间线就变得在数学上不可动摇。
以下是该指纹在 Git 中的样子：
# Git 为精确的仓库状态创建唯一指纹
git rev-parse HEAD
# 6f1ed002ab5595859012f3f9b6b4c2b1e1c9a2e5
该哈希代表了提交时完整的仓库状态。改变一个字节，哈希就会完全改变。哈希本身无法被逆向以还原你的源代码。
一个简单的类比：公证人与保险箱
想象你带着一个密封的信封走进公证处。公证人不会打开它。相反，他们记录日期，在外侧盖章，并在登记簿上签字。多年后，你可以在法庭上打开信封，证明其中的内容在那个日期已经存在，因为公证人的记录是独立的且具有防篡改性。
软件的存在性证明以同样的方式运作，只不过“信封”是加密哈希，而“公证人”是比特币区块链。
- 你保持代码私密。 公证人——在这里是时间戳服务和公共账本——只能看到指纹。
- 记录是独立的。 比特币区块链是一个没有任何单一供应商控制的公共账本。一旦交易在一个区块中得到确认，篡改该记录在计算上是不切实际的。
- 证据不依赖于供应商而存在。 因为证明锚定在比特币中，即使时间戳服务消失，你仍然可以验证它。
这个类比有助于非技术利益相关者理解为什么区块链时间戳不同于内部 Git 日志。内部日志存在于你控制或租用的基础设施上。比特币锚定的证明是公开的、不可变的，并且可以独立验证。
存在性证明的底层工作原理
这个过程可以分为三个步骤。
第一步：指纹
Git 已经为你完成了第一步。每个提交都会获得一个唯一的哈希——旧版 Git 中使用 SHA-1，较新的仓库支持 SHA-256——它覆盖了该时间点的完整仓库状态。
这个哈希不是你的代码。它是一个固定大小的数学摘要。你无法从中重建源代码，而且相同的代码状态总是产生相同的哈希。
第二步：锚定
下一步是将哈希锚定到公共账本中。Timestamp GIT 收集提交哈希，并将它们分组到每日清单文件中。它从这些哈希构建 Merkle 树，并创建 OpenTimestamps 证明。Merkle 根随后被锚定到一笔比特币交易中。
一旦该交易在比特币区块中得到确认，时间戳就变得不可变。没有删除按钮，没有管理覆盖，也没有可以在之后被编辑的专有数据库。
流程如下所示：
commit hash -> daily manifest -> Merkle tree -> Bitcoin transaction -> .ots receipt
第三步：证明
输出是一个加密收据，通常是一个 .ots 文件。该收据允许任何人使用标准的 OpenTimestamps 工具对照比特币区块链验证时间戳。
这一点很重要：证明依赖于 SHA-256 和比特币区块数据。不存在对单一供应商格式或基础设施的锁定。即使 SaaS 提供商不再存在，证明仍然可以验证。
使用原始 OpenTimestamps 工具手动完成这一过程是可能的，但这意味着你需要自己处理日历、Merkle 树和比特币确认监控。这种手动复杂性正是 Timestamp GIT 通过在 GitHub App 背后自动化整个流程所消除的。
为什么存在性证明对开发者和合规很重要
存在性证明之所以重要，是因为时间往往是知识产权争议中的核心问题。
- 专利流氓： 针对宽泛软件专利的一种常见抗辩是现有技术。如果你能证明你的代码在申请日之前已经存在，专利主张可能无效。存在性证明将你的私有仓库转变为一份有日期、可验证的现有技术记录。更多详情，请参阅如何证明你的代码在专利申请之前已经存在。
- 员工和客户争议： 当开发者离职，或客户质疑某个里程碑何时完成时，带有时间戳的提交哈希比导出的聊天记录或被编辑过的 Git 历史更有说服力。
- 合规与治理： 需要为安全审查、尽职调查或内部治理提供审计追踪的团队，可以展示代码状态何时存在的定期、可验证记录。
还有一些常见的误解需要澄清。
- 它不是版权登记。 区块链时间戳不能替代版权登记，它本身也不能证明作者身份。
- 它不能证明是谁写了代码。 它证明的是某个哈希在某个时间已经存在。作者身份仍然需要雇佣记录、提交元数据或其他证据。
- 它不是“仅仅一个内部日志”。 Git 历史可以被改写、强制推送或丢失。比特币锚定的证明是外部的、公开的，并且在数学上可验证。
Timestamp GIT 如何让存在性证明变得毫不费力
Timestamp GIT 是一个托管 SaaS 和 GitHub App，自动化了整个存在性证明流程。你无需运行 OpenTimestamps 命令、管理日历或直接与比特币交互。
主要工作流程是：
- 安装一次 GitHub App。
- 选择你想要监控的仓库。
- 像平常一样继续提交代码。
每天晚上，Timestamp GIT 自动将待处理的提交哈希分组，构建 Merkle 树，创建 OpenTimestamps 证明，并将 Merkle 根锚定到比特币区块链中。在比特币确认之后——通常大约三小时——清单和 .ots 收据文件会被推送回一个专门的时间戳分支或影子仓库。
关键特性：
- 零知识设计。 Timestamp GIT 永远不会看到、复制或存储你的源代码。它只处理提交哈希。
- 无需手动步骤。 无需在开发者机器上安装 CLI 工具，也无需构建原始比特币交易。
- 灵活部署。 标准模式使用 GitHub App，需要对源仓库的读取权限和对目标仓库的读写权限。企业零知识模式使用你基础设施上的 GitHub Action，仅将提交哈希推送到 Timestamp GIT API，因此该服务完全不需要对源仓库的读取权限。
- 公开验证。 你可以在 README 中嵌入状态徽章，查看公开状态页面，下载审计 CSV，或生成 PDF 证书。
- 供应商独立性。 即使 Timestamp GIT 停止运营，
.ots收据也可以使用标准 OpenTimestamps 工具离线验证。
对于自托管或隔离环境，可以使用 Docker 镜像：
services:
timestampgit:
image: rue1401/timestampgit:prod
ports:
- "8080:8080"
volumes:
- ./data:/app/data
restart: unless-stopped
valkey:
image: valkey/valkey:8
restart: unless-stopped
你也可以直接查询公开状态端点，例如：
curl https://timestampgit.dev/api/statusLast/your-org/your-repo
该端点返回被监控仓库最近一次锚定的比特币区块信息。
常见问题
存在性证明在法律上被认可吗？
加密时间戳在法庭上越来越被接受为现有技术的证据。它们提供了强有力的、防篡改的记录，可以独立验证。然而，法律认可因司法管辖区而异，建议就具体案件咨询律师。
存在性证明会泄露我的源代码吗？
不会。存在性证明使用加密哈希，这是单向函数。实际源代码永远不会被传输或存储。只有哈希被锚定到区块链上，因此你的代码保持私密。
为我的代码加时间戳需要多少费用？
Timestamp GIT 为公开仓库提供免费套餐。私有仓库的付费计划从每月 49 美元起，企业零知识计划为每月 199 美元。也提供自托管 Docker 许可证。
我可以在不依赖 Timestamp GIT 的情况下验证时间戳吗？
可以。证明基于 OpenTimestamps 协议和比特币区块链。你可以下载 .ots 收据，并使用标准 OpenTimestamps 工具进行验证，即使 Timestamp GIT 不复存在。
结论
软件代码的存在性证明是少数几种同时具备低成本、数学严谨性，并且在法律和合规场景中都有用的开发者工具之一。它不能证明作者身份或所有权，但它创建了一个极难被质疑的固定时间点。
困难的方式是手动运行 OpenTimestamps 协议。实用的方式是安装 Timestamp GIT GitHub App，连接你的仓库，让每晚的锚定流程完成剩下的工作。立即在 Timestamp GIT 开始为你的提交加时间戳。
相关文章
