用区块链证明保护代理机构代码交付物
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，让每夜锚定运行，并把证书附在你下一张发票上。一次性大约十分钟，它会改变之后每一次交付对话的基调。
相关文章
