什么是软件代码的存在性证明？
对于开发者和合规团队来说，“存在性证明”并不是要证明所有权或作者身份。它只回答一个核心问题：这段确切的代码是否在某个时间点已经存在？ 在一个 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 开始为你的提交打时间戳。
相关文章
