用区块链证明保护代理机构代码交付物
Elena 经营着一家五人开发工作室。十一个月前，她与一位客户签下了客户门户项目：三个里程碑，固定价格，交付即开票。第一个和第二个里程碑都很顺利。第三个里程碑在九月的一个周五交付——功能完整、测试通过、部署到客户的预发布环境。然后发票寄出，客户却沉默了。
两周后，回复来了：“报表模块从未真正交付。我们不会支付尾款，而且我们要求就延期给予补偿。”
Elena 有证据。算是吧。有一封邮件往来，客户自己的产品经理在里面写道“看起来不错，我们下周测试”。有一个共享的 Google Drive 文件夹，里面是导出的规格文档。还有那个 GitHub 仓库——400 多次提交，截止时间恰好就是她所说的那个时间，报表模块在开票前六周就已交付。
这些都不是中立的。邮件往来是一场截图大战。Drive 文件夹里的文件，其修改日期客户可以（而且确实）质疑。Git 历史存放在客户共同拥有的组织里，而提交日期只需一次 git rebase 加一次强制推送就能改写。在付款纠纷中，“我们有内部日志”几乎一文不值——那是你在自己控制的系统上、关于你自己生成的证据。
本文是一份实用手册，面向那些想要相反结果的代理机构：一份双方都无法控制的记录，一份无需客户善意即可验证的记录，一份即使客户更换仓库、更换托管服务商或改口说辞也依然成立的记录。
存在性的密码学证明恰好能解决这个问题。而且自 2026 年起，你无需理解密码学就能使用它——托管层会替你完成这些工作。
为什么区块链证明对代理机构很重要（不只是专利流氓）
区块链时间戳常被归入“专利防御”一类，这也是为什么大多数代理机构直到需要它时才注意到它。但对一家开发工作室来说，专利流氓并不是日常风险。有现金流问题的客户才是。
以下是比特币锚定的提交记录能回本的四个具体场景：
- 付款纠纷。 你可以证明某个里程碑被提交的确切日期——不是发票寄出的时间，不是某人在 Slack 里说“完成了”的时间。这个日期源自比特币区块，而不是你的服务器时钟或客户的时钟。
- 责任规避。 范围蔓延的争论通常取决于某件事是何时达成一致的，与何时被构建的。一份不可篡改的、按天记录项目各阶段存在内容的记录，让你能够证明变更请求是在交付之后才提出的，而无需争论任何人的日历。
- 作品集与复用保护。 大多数代理机构都有一套组件库——一个认证模块、一个计费适配器、一个 CMS 集成——它们会出现在十几个客户项目中。证明你创作了它以及创作时间，能在前客户声称你盗用其代码时保护你。
- 将客户信任作为一项特性。 一份包含可验证作者证明的交付包，在采购谈判中读起来的感觉，与一份包含你自己生成的 PDF 的交付包截然不同。
这主要不是一个专利故事。如果你想要的是现有技术角度——使宽泛专利无效、在申请前保护商业秘密——那在另一篇关于软件初创企业的现有技术保护的文章中有详细说明。这里我们聚焦于商业关系。
实用手册：为代理机构仓库设置区块链证明
整个设置共五步，其中四步是一次性的。这里没有任何内容要求你的开发者学习新工具或更改任何一条命令。
第 1 步——安装 Timestamp GIT GitHub App
在你用于客户工作的仓库上安装该应用。在标准模式下，GitHub App 会自动读取每个受监控仓库的 HEAD 提交哈希，并将证明写入一个专用分支（可以放在同一仓库中，也可以放在单独的影子仓库中，由你选择）。它需要对源仓库的只读访问权限，以及对证明落地的目标仓库的读写访问权限。
在合作开始时一次性完成，而不是在纠纷开始之后。在争执期间创建的时间戳，其价值远不及在正常交付期间创建的时间戳。
第 2 步——让每晚锚定自动运行
没有逐次提交的步骤。提交哈希通过 webhook 检测并排队到内存中。每晚，一个 worker 会批量处理所有待处理项，为每个仓库构建清单文件，构造一棵 Merkle 树，并通过 OpenTimestamps 协议使用公共日历将 Merkle 根锚定到比特币区块链中。
比特币确认通常需要大约三个小时，因此证明会在批处理运行几小时后写回。从你的角度来看：你推送代码，到第二天早上，前一天的工作就已被锚定。
第 3 步——把验证徽章摆到客户面前（礼貌地）
可嵌入的徽章可用于你的 README 和交付报告。任何拿到链接的人都可以通过公开状态页面验证时间戳——无需账户，无需登录。
# Get ready-made badge markdown for your delivery report or README
curl -s https://timestampgit.dev/api/badgeLink/your-agency/client-portal
该徽章是一个兼容 Shields.io 的片段，因此可以放入 README、Notion 页面，或你随发票一起发送的 PDF 中。在私有仓库上，状态 URL 携带加密的 HMAC，因此只有授权人员才能读取状态——证明本身保持公开且可验证，元数据不会泄露。
第 4 步——在里程碑处导出证书和审计账本
在每个里程碑处，取出书面材料并附在发票上。
# Full audit ledger as CSV — every anchored commit, every date
curl -s -o audit-client-portal.csv \
"https://timestampgit.dev/api/audit/your-agency/client-portal"
# Per-day PDF certificate — include with the handover pack
curl -s -o certificate-2026-09-30.pdf \
"https://timestampgit.dev/api/report/your-agency/client-portal/2026-09-30"
仓库状态页面以可视化方式提供相同数据：证明存续时间、最早锚定日期、每日规律性、每次锚定背后的比特币区块和交易、日历热力图，以及可下载的 CSV 和 PDF。如果你想把数据接入内部仪表盘，/api/statusSummary/{user}/{repo} 端点会返回一份合并摘要。
第 5 步——（可选）面向敏感客户的 Enterprise ZK 模式
某些客户合同——国防、金融科技，任何带有严格知识产权条款的——禁止第三方访问源代码。Enterprise ZK 模式解决了这个问题：一个 12 行的 GitHub Action 在你的基础设施内运行，只将提交哈希推送到 Timestamp GIT API。你的源代码永远不会离开你的环境，而且只有目标仓库需要写访问权限。
可选：自托管 Docker
如果客户要求气隙运行或数据驻留在你自己的硬件上，Timestamp GIT 以 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 连接和实例配置。用于评估的限时演示许可证可从 Docker 许可证页面申请。
在客户工作中使用区块链证明时应避免什么
代理机构在这里会犯的五个错误，大致按频率从高到低排列：
- 仅依赖内部 Git 日志。 它们可编辑，存储在你或客户控制的基础设施上，在审计中会被视为自利证据而不予采信。来自 GitHub 的提交日期是一种主张；比特币区块内的提交哈希才是证据。
- 试图手工完成协议。 你可以用 CLI 工具和自己的日历提交来驱动底层的 OpenTimestamps 机制——但这是艰难的方式，它需要一套你的开发者会忘记的逐次提交流程，而且它产生的结果与你想要的完全相同，维护成本却大约高出一百倍。托管层存在的意义，就是让你团队中没有人需要去考虑它。
- 只在项目结束时打时间戳。 单一的项目结束证明只说明“此物在 X 日存在”。每晚的链条则说明“这次提交在这个日期存在，那次提交在那个日期存在，一路贯穿始终”。当客户争议的是时间线而非某个交付物时，粒度就是整个案件的关键。
- 把证明留给自己。 对方无法核验的证明，就是他们会质疑的证明。把徽章放进 README，发送状态链接，附上 PDF 证书。
- 忽视客户的隐私要求。 如果合同禁止第三方访问代码，请使用 Enterprise ZK 模式或自托管。不要悄悄假设“仅哈希”就能满足一条写着“不得有第三方”的条款。
Timestamp GIT 如何融入你的代理机构工作流
其设计目标是让时间戳在你需要它之前都是隐形的：
- 开发者零设置。 安装一次 GitHub App。对受监控仓库的每次提交都会自动排队；批处理每晚运行。没有新命令，开发者机器上无需安装任何东西。
- 零知识架构。 Timestamp GIT 从不查看、复制或存储你的源代码。它只对提交哈希打时间戳。第一步中的指纹是仓库状态的单向哈希——你的实现细节无法从中恢复。
- 供应商无关的验证。 证明是一份锚定在比特币中的
.ots收据。验证依赖于 SHA-256 和比特币区块数据——没有专有格式。任何人都可以下载收据，并用标准 OpenTimestamps 工具对照区块链进行检查，即使 Timestamp GIT 明天就消失了也没关系。在如何验证 Git 仓库的比特币时间戳中有一份分步指南。 - 契合代理机构文书工作的集成点。 用于状态、审计 CSV 和 PDF 证书的 REST API；用于 README 和交付文档的可嵌入徽章；客户可以收藏的公开状态页面。
- 匹配代理机构规模的定价。 开源（免费）用于公共仓库，Pro Agency 每月 49 美元用于私有仓库，当合同要求隔离时 Enterprise ZK 每月 199 美元。详情见定价页面。
对于想要了解机制而非手册的团队，技术配套文章是自动化 Git 时间戳：GitHub App 如何锚定每一次提交。
常见问题
我需要改变开发者提交代码的方式吗？
不需要。一旦 Timestamp GIT GitHub App 安装到仓库上，每次提交都会被自动检测，其哈希会被排队等待每晚的比特币锚定。开发者继续使用他们正常的 Git 工作流，无需额外命令或工具。
客户能自己验证证明吗？
可以。你可以在 README 或交付报告中嵌入一个验证徽章，链接到公开状态页面。客户也可以下载 .ots 收据文件，并使用标准 OpenTimestamps 工具对照比特币区块链独立验证。
如果客户要求任何第三方都不得查看代码怎么办？
使用 Enterprise ZK 模式，其中一个 12 行的 GitHub Action 在你的基础设施上运行，只将提交哈希推送到 Timestamp GIT API。你的源代码永远不会离开你的环境。或者，你可以使用提供的 Docker 镜像自托管 Timestamp GIT，以获得完全控制权。
一次提交被锚定到比特币需要多长时间？
提交哈希每天批量处理，并通过 OpenTimestamps 协议锚定到比特币区块中。比特币确认通常需要大约三个小时，之后证明就不可篡改且可验证。
这会取代合同吗？
不会。它取代的是合同纠纷中最薄弱的部分：关于何时存在何物的客观事实记录。你的合同决定谁欠什么；时间戳决定某个特定日期上什么是真实的。
结论
Elena 的纠纷以这类事情通常的方式解决了——部分付款，失去一个客户。令人沮丧的不是钱。而是她明明是对的，却没有任何第三方会接受的方式来证明这一点。
这就是区块链证明为代理机构填补的空白。不是专利战，不是抽象的未来——而是那个普通的星期二，客户决定发票是可选的，而你唯一的防御就是一份你们双方都无法编辑的记录。
在你的客户仓库上安装 Timestamp GIT GitHub App，让每晚锚定自动运行，并把证书附在你下一张发票上。一次性大约十分钟，之后它会改变每一次交付对话的基调。
相关文章
