Timestamp GIT Secure your prior art without exposing code

← Tutti gli articoli

2026-09-10

Timestamp GIT vs OpenTimestamps: gestito vs fai-da-te

Timestamp GIT vs OpenTimestamps: gestito vs fai-da-te
timestamp git blockchain proof

Timestamp GIT vs OpenTimestamps:托管服务与自行搭建

timestamp git vs opentimestamps 的选择归结为一点:你是想自己运行时间戳基础设施,还是想以服务的形式消费时间戳功能?

Timestamp GIT 采用 OpenTimestamps 协议,将运维复杂性隐藏在 GitHub App、自动夜间锚定、Web 仪表盘、徽章和 REST API 之后。原生 OpenTimestamps 提供相同的底层密码学原语——将 SHA-256 哈希锚定到比特币区块链中——但要求你自己处理哈希计算、批量处理、任务调度、回执存储和验证。

两种方案都会生成 .ots 回执,证明你的 Git 提交历史在某个特定比特币区块之前就已存在。区别在于,由你负责还是由托管服务负责可靠地生成这些回执。

选择:托管时间戳服务 vs. 自行搭建 OpenTimestamps

购买决策很简单。你需要密码学上不可否认的证据,证明某个 Git 提交在特定日期存在。原生协议能做到这一点。构建在该协议之上的托管服务也能做到这一点。权衡在于:

  • Timestamp GIT:自动化、易用、合规就绪的证据、供应商运营的基础设施、私有仓库的付费套餐。
  • OpenTimestamps:完全控制、开源透明、零许可费用,但需要手动工具和自定义自动化。

对于许多团队来说,正确的评估不是“哪个在密码学上更强?”,因为比特币锚定的数学原理是相同的。正确的评估是“哪个方案能在六个月后仍然持续产出回执、徽章和审计报告,而不需要团队里有人守着 cron 任务?”

这就是本文要展开的比较。

全景:通往比特币锚定证明的两条路径

OpenTimestamps 是一个开源协议,用于将数据哈希锚定到比特币区块链中。它使用 SHA-256 和比特币区块数据来创建时间戳证明。核心输出是 .ots 回执。它不是托管产品;你需要安装工具、决定对什么进行哈希,并自行运行整个流程。它默认没有仪表盘、没有徽章生成器,也没有仓库集成。验证同样需要手动操作:你需要针对比特币区块数据运行协议工具。

Timestamp GIT 是一个构建在 OpenTimestamps 之上的托管 SaaS + GitHub App。你只需安装一次 GitHub App。此后,被监控仓库的每一次提交都会被自动检测,在夜间清单中批量处理,合并到 Merkle 树中,通过公共 OTS 日历锚定到比特币,并将证明返回到专用分支或影子仓库。无需在开发者机器上安装 CLI。无需维护 cron 任务。该产品还提供 Docker 自托管选项,适用于需要在自身基础设施内使用托管工作流的场景。

两条路径都会生成锚定在比特币区块链中的 .ots 回执。证明格式和密码学保证在本质上是相同的。用户体验和运维范围则不然。

选择标准:对开发者和合规团队而言什么最重要

设置便捷性与持续使用

Timestamp GIT 需要安装 GitHub App 并连接仓库。无需本地工具、无需调度器、无需管理回执存储。有一个细节需要注意:由于 GitHub 不提供仅提交哈希的权限,标准模式下的 GitHub App 会请求对源仓库的只读访问权限——但它只读取 HEAD 提交哈希。它还需要对写入回执的目标证明仓库或分支具有读写权限。

OpenTimestamps 需要安装协议工具、编写脚本、调度任务和存储回执。对于单个仓库来说并不难,但在整个组织中就会变成实实在在的维护工作。

自动化与可靠性

Timestamp GIT 处理完整的流水线:

  1. 通过 GitHub webhook 或 GitHub Action 检测提交。
  2. 在内存键值存储中排队哈希。
  3. 夜间工作进程将待处理的哈希分组到清单文件中,构建 Merkle 树,创建 OpenTimestamps 证明,并将 Merkle 根锚定到比特币。
  4. 在比特币确认后交付证明,通常需要几个小时。

OpenTimestamps 没有内置自动化。提交检测、批量处理、调度和回执交付都需要你自己完成。

安全性与零知识

两种方案都可以实现零知识。Timestamp GIT 永远不会看到、复制或存储你的源代码。在标准模式下,GitHub App 只读取 HEAD 提交哈希。在企业零知识模式下,GitHub Action 在你的基础设施上运行,只将提交哈希推送到 Timestamp GIT API。你的源代码永远不会离开你的环境。

原生 OpenTimestamps 允许你在本地进行哈希,只对摘要进行时间戳。区别在于,Timestamp GIT 已经通过 GitHub App 权限模型和受 HMAC 保护的零知识 API 将这一边界产品化了。

与现有工作流的集成

Timestamp GIT 开箱即用地融入 GitHub 工作流。它提供:

  • README 验证徽章
  • 包含比特币区块和交易数据的公开状态仪表盘
  • 审计 CSV 导出
  • 按日期生成的 PDF 证书
  • 用于状态、徽章、验证和报告的 REST API 端点

私有仓库的徽章 URL 会附加加密的 HMAC,只有授权用户才能看到状态。OpenTimestamps 提供原始的 .ots 文件;要将这些文件转化为徽章、仪表盘或合规导出,需要自定义工具。

使用 Docker 自托管

如果你需要托管工作流但必须将一切保留在内部,Timestamp GIT 也以 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
docker compose pull
docker compose up -d
docker compose logs -f timestampgit

启动后,应用可在 http://localhost:8080 访问。首次启动时,设置向导会引导你连接 GitHub App 并配置实例。

定价

Timestamp GIT 为公共仓库提供免费套餐,Pro Agency 计划为 $49/月(适用于私有仓库),Enterprise ZK 为 $199/月(基于 GitHub Actions 的零知识时间戳)。Docker 自托管许可证可通过演示许可证申请获取。

OpenTimestamps 是免费的开源软件,但真正的成本是工程时间、脚本、监控,以及流水线在你需要证明之前悄然失效的风险。

并排对比:Timestamp GIT vs OpenTimestamps

标准 Timestamp GIT 原生 OpenTimestamps
设置时间 安装一次 GitHub App;连接仓库。无需在开发者机器上安装。 安装协议工具、编写脚本、调度任务、管理回执存储。
自动化 自动夜间批量处理、Merkle 树构建、OTS 证明创建和证明交付。 手动;所有自动化都是你自己的代码。
用户界面 Web 仪表盘、设置向导、仓库状态页面、徽章。 CLI 和原始 .ots 回执文件。
验证 基于浏览器的公开 Merkle 链验证、PDF 证书、审计 CSV、API 端点。 使用协议工具针对比特币区块数据进行手动验证。
合规功能 README 徽章、每日规律性日历、审计台账 CSV、PDF 证书。 仅原始回执;合规导出需要自定义工具。
零知识 标准模式仅读取 HEAD 提交哈希;企业零知识模式仅从你的 Action 推送哈希。 你在本地选择要时间戳的内容。
定价 公共仓库免费;$49/月 Pro Agency;$199/月 Enterprise ZK;提供 Docker 自托管许可证。 免费开源软件,但需要工程时间和基础设施成本。
维护负担 具有自动化流水线的托管服务。 自管理脚本、cron 任务、监控。

密码学强度不是差异化因素:两种方案都使用相同的 SHA-256 哈希和通过 OpenTimestamps 协议进行的比特币锚定。证明是相同的。运维体验则不然。

结论:谁应该选择哪个?

选择 Timestamp GIT,如果你想要一个零配置、自动化的解决方案,能够融入 GitHub 工作流,并在无需学习底层协议的情况下产出合规就绪的证据。对于大多数初创公司、开发工作室、自由职业者和内部团队来说,这是务实的路径。

选择原生 OpenTimestamps,如果你有特定的技术要求,希望对时间戳过程的每一步都有完全控制,并且能够自如地管理基础设施。这对于协议研究者、非 Git 数据或自定义批量流水线来说可能更合适。

考虑 Docker 自托管选项,如果你需要 Timestamp GIT 的托管工作流,但由于气隙隔离、安全或合规原因必须将一切保留在内部。

对于大多数开发者和合规团队来说,Timestamp GIT 在安全性、便利性和法律可辩护性之间提供了最佳平衡。

常见问题

Timestamp GIT 只是 OpenTimestamps 的封装吗?

是的,Timestamp GIT 在底层使用 OpenTimestamps 协议将提交哈希锚定到比特币区块链中。但它自动化了整个流程:你安装 GitHub App,每个提交都会在夜间自动完成时间戳,无需任何手动 CLI 命令。生成的 .ots 证明与你手动创建的完全相同。

我能否从原生 OpenTimestamps 切换到 Timestamp GIT 而不丢失现有证明?

可以,你现有的 OpenTimestamps 证明仍然有效,因为它们已经锚定在比特币区块链中。Timestamp GIT 可以从你连接仓库的时间点开始为新的提交添加时间戳,你可以保留旧回执用于历史验证。

Timestamp GIT 会看到我的源代码吗?

不会,Timestamp GIT 的设计是零知识的。在标准模式下,GitHub App 只读取 HEAD 提交哈希,而不是代码本身。在企业零知识模式下,GitHub Action 在你的基础设施上运行,只将提交哈希推送到 API,因此你的源代码永远不会离开你的环境。

Timestamp GIT 的比特币锚定安全性与手动 OpenTimestamps 一样吗?

是的,安全性完全相同,因为两者都使用相同的 OpenTimestamps 协议和比特币区块链。Timestamp GIT 将多个提交哈希批量合并到 Merkle 树中,并将根锚定在比特币交易中,就像你手动操作一样。区别在于 Timestamp GIT 为你处理了技术细节。

结语:为你的在先技术做出正确选择

Timestamp GIT 和原生 OpenTimestamps 都能生成数学上不可否认的证明,证明你的 Git 提交在特定时间点存在。底层的比特币锚定数学原理是相同的。区别在于运维层面:一个是自动化整个流水线的托管 GitHub App,另一个是你必须自行运行的协议。

如果你重视时间、简洁性和合规就绪的证据,Timestamp GIT 是务实的选择。你只需安装一次 GitHub App,连接你的仓库,让夜间锚定完成剩下的工作——同时你的源代码保持私密。

在公共仓库上免费试用 Timestamp GIT,或者如果你需要在自身基础设施内使用相同的工作流,可以探索 Docker 自托管选项。

相关文章

EU label: AI-generated content