Защита результатов работы агентства с помощью блокчейн-доказательств

Елена руководит небольшой студией разработки из пяти человек. Одиннадцать месяцев назад она подписала контракт с клиентом на создание клиентского портала: три этапа, фиксированная цена, оплата по факту сдачи. Первый и второй этапы прошли гладко. Третий этап был сдан в пятницу в сентябре — функциональность готова, протестирована, развёрнута в staging-окружении клиента. Затем пришёл счёт, и клиент замолчал.

Две недели спустя ответ: «Модуль отчётности так и не был поставлен. Мы не оплачиваем финальный счёт и требуем компенсацию за задержку».

У Елены есть доказательства. Вроде бы. Есть цепочка писем, где продакт-менеджер самого клиента написал «выглядит хорошо, протестируем на следующей неделе». Есть общая папка в Google Drive с экспортированными спецификациями. И есть репозиторий на GitHub — более 400 коммитов, заканчивающихся ровно тогда, когда она говорит, причём модуль отчётности был сдан за шесть недель до выставления счёта.

Ничто из этого не является нейтральным. Цепочка писем — это война скриншотов. В папке Drive есть файлы, даты изменения которых клиент может (и оспорил) поставить под сомнение. История Git находится в организации, совладельцем которой является клиент, а даты коммитов можно переписать одним git rebase и force push. В споре об оплате «у нас есть внутренние логи» не стоит практически ничего — это доказательство, которое вы создали о себе сами, в системах, которые вы контролируете.

Эта статья — практическое руководство для агентств, которые хотят обратного: запись, которую не контролирует ни одна из сторон, для проверки которой не нужна добрая воля клиента и которая выживает, даже если клиент изменит репозиторий, хостинг-провайдера или саму историю.

Криптографическое доказательство существования решает именно эту задачу. А с 2026 года вам не нужно разбираться в криптографии, чтобы этим пользоваться — всю работу делает управляемый слой.

Почему блокчейн-доказательства важны для агентств (а не только для патентных троллей)

Блокчейн-проставление меток времени относят к категории «защита от патентов», поэтому большинство агентств игнорируют его, пока он не понадобится. Но патентные тролли — не повседневный риск для студии разработки. Повседневный риск — это клиенты с проблемами денежного потока.

Четыре конкретные ситуации, где запись коммитов, привязанная к Биткоину, окупает себя:

• Споры об оплате. Вы можете доказать точную дату сдачи этапа — не когда был отправлен счёт, не когда кто-то написал «готово» в Slack. Дата берётся из блока Биткоина, а не из часов вашего сервера или клиента.
• Защита от ответственности. Споры о расширении объёма работ обычно упираются в то, когда что-то было согласовано, а когда построено. Неизменяемая запись по дням о том, что существовало на каждом этапе проекта, позволяет показать, что запрос на изменение появился после сдачи, не споря о чьём-либо календаре.
• Защита портфолио и повторного использования. Большинство агентств имеют библиотеку компонентов — модуль аутентификации, платёжный адаптер, интеграцию с CMS, — которая появляется в десятке клиентских проектов. Доказательство того, что вы её автор и когда создали, защищает вас, если бывший клиент заявит, что вы украли его код.
• Доверие клиента как преимущество. Пакет сдачи, включающий проверяемый сертификат авторства, читается иначе на переговорах о закупке, чем пакет с PDF, который вы сгенерировали сами.

Это не в первую очередь патентная история. Если вам нужен аспект prior art — аннулирование широких патентов, защита коммерческой тайны до подачи заявки — это освещено в соседней статье о защите prior art для софтверных стартапов. Здесь мы остаёмся в рамках коммерческих отношений.

Практическое руководство: настройка блокчейн-доказательств для репозиториев агентства

Вся настройка состоит из пяти шагов, и четыре из них — одноразовые. Ничто здесь не требует, чтобы ваши разработчики изучали новый инструмент или меняли хоть одну команду.

Шаг 1 — Установите GitHub App Timestamp GIT

Установите приложение на репозитории, которые вы используете для клиентской работы. В стандартном режиме GitHub App автоматически считывает хеш HEAD-коммита каждого отслеживаемого репозитория и записывает доказательства в выделенную ветку (в том же репозитории или в отдельном теневом репозитории — на ваш выбор). Требуется доступ только на чтение к исходному репозиторию и на чтение-запись к целевому репозиторию, куда попадают доказательства.

Сделайте это один раз, в начале работы, а не после начала спора. Метка времени, созданная во время разногласий, стоит лишь малую долю той, что создана в ходе обычной сдачи работы.

Шаг 2 — Позвольте ночному анкорингу работать

Никакого шага на каждый коммит нет. Хеши коммитов определяются через вебхуки и ставятся в очередь в памяти. Каждую ночь воркер собирает всё ожидающее, формирует файлы манифеста по каждому репозиторию, строит дерево Меркла и привязывает корень Меркла к блокчейну Биткоина через протокол OpenTimestamps с использованием публичных календарей.

Подтверждение Биткоина обычно занимает около трёх часов, поэтому доказательства записываются обратно через несколько часов после запуска пакета. С вашей стороны: вы пушите код, и к следующему утру вчерашняя работа привязана.

Шаг 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 — (Опционально) Корпоративный ZK-режим для чувствительных клиентов

Некоторые клиентские контракты — оборонка, финтех, всё со строгим пунктом об интеллектуальной собственности — запрещают доступ третьих лиц к исходному коду. Корпоративный ZK-режим решает это: GitHub Action из 12 строк запускается внутри вашей инфраструктуры и отправляет в API Timestamp GIT только хеши коммитов. Ваш исходный код никогда не покидает вашу среду, и доступ на запись нужен только целевому репозиторию.

Опционально: self-hosted 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 — это утверждение; хеш коммита внутри блока Биткоина — это доказательство.
• Пытаться делать протокол вручную. Вы можете управлять базовой механикой OpenTimestamps самостоятельно с помощью CLI-инструментов и собственных отправок в календари — это трудный путь, он требует рабочего процесса на каждый коммит, о котором ваши разработчики забудут, и даёт ровно тот же результат при примерно стократных затратах на поддержку. Управляемый слой существует, чтобы никто в вашей команде вообще об этом не думал.
• Проставлять метки времени только в конце проекта. Единичное доказательство в конце проекта говорит «это существовало в дату X». Ночная цепочка говорит «этот коммит существовал в эту дату, а тот коммит — в ту, и так по всей длине». Когда клиент оспаривает сроки, а не результат, гранулярность — это и есть всё дело.
• Держать доказательство при себе. Доказательство, которое другая сторона не может проверить, — это доказательство, которое она оспорит. Поместите значок в README, отправьте ссылку на статус, приложите PDF-сертификат.
• Игнорировать требования клиента к приватности. Если контракт запрещает доступ третьих лиц к коду, используйте корпоративный ZK-режим или self-hosting. Не предполагайте молча, что «только хеши» удовлетворяют пункту, который гласит «никаких третьих лиц».

Как Timestamp GIT вписывается в рабочий процесс вашего агентства

Цель дизайна — чтобы проставление меток времени было незаметным, пока оно вам не понадобится:

• Ноль настройки для разработчиков. Установите GitHub App один раз. Каждый коммит в отслеживаемый репозиторий ставится в очередь автоматически; пакет запускается ночью. Никаких новых команд, ничего устанавливать на машины разработчиков.
• Архитектура с нулевым разглашением. Timestamp GIT никогда не видит, не копирует и не хранит ваш исходный код. Он проставляет метки на хеши коммитов. Отпечаток на первом шаге — это односторонний хеш состояния репозитория; ничего о вашей реализации из него не восстановить.
• Независимая от вендора верификация. Доказательство — это квитанция .ots, привязанная к Биткоину. Проверка зависит от SHA-256 и данных блоков Биткоина — никакого проприетарного формата. Любой может скачать квитанцию и проверить её стандартными инструментами OpenTimestamps по блокчейну, даже если Timestamp GIT исчезнет завтра. Пошаговое руководство есть в статье как проверить метку времени Биткоина для Git-репозитория.
• Точки интеграции, подходящие для документооборота агентства. REST API для статуса, CSV аудита и PDF-сертификатов; встраиваемые значки для README и документов о сдаче; публичная страница статуса, которую клиенты могут добавить в закладки.
• Цены, соответствующие масштабу агентства. Open Source (бесплатно) для публичных репозиториев, Pro Agency за $49/мес для приватных репозиториев, Enterprise ZK за $199/мес, когда контракт требует изоляции. Подробности на странице цен.

Для команд, которым нужна механика, а не руководство, техническая сопутствующая статья — автоматическое проставление меток времени Git: как GitHub App привязывает каждый коммит.

FAQ

Нужно ли менять то, как мои разработчики коммитят код?

Нет. Как только GitHub App Timestamp GIT установлено на репозиторий, каждый коммит определяется автоматически, а его хеш ставится в очередь на ночной анкоринг в Биткоин. Разработчики продолжают использовать свой обычный рабочий процесс Git без дополнительных команд или инструментов.

Могут ли клиенты сами проверить доказательство?

Да. Вы можете встроить значок верификации в свой README или отчёт о сдаче, который ведёт на публичную страницу статуса. Клиенты также могут скачать файл квитанции .ots и проверить его независимо по блокчейну Биткоина стандартными инструментами OpenTimestamps.

Что если клиент требует, чтобы никакая третья сторона никогда не видела код?

Используйте корпоративный ZK-режим, где GitHub Action из 12 строк запускается на вашей инфраструктуре и отправляет в API Timestamp GIT только хеши коммитов. Ваш исходный код никогда не покидает вашу среду. Как вариант, вы можете развернуть Timestamp GIT самостоятельно с помощью предоставленного Docker-образа для полного контроля.

Сколько времени занимает привязка коммита к Биткоину?

Хеши коммитов собираются в пакеты ежедневно и привязываются к блоку Биткоина через протокол OpenTimestamps. Подтверждение Биткоина обычно занимает около трёх часов, после чего доказательство неизменяемо и проверяемо.

Заменяет ли это контракт?

Нет. Это заменяет самую слабую часть контрактного спора: фактическую запись о том, что существовало когда. Ваш контракт определяет, кто кому что должен; метка времени определяет, что было верно на данную дату.

Заключение

Спор Елены разрешился так, как это обычно и бывает — частичной оплатой и потерянным клиентом. Раздражала не сумма. Раздражало то, что она была права и не имела способа это продемонстрировать так, чтобы третья сторона это приняла.

Именно этот пробел блокчейн-доказательства закрывают для агентств. Не патентная война, не абстрактное будущее — обычный вторник, когда клиент решает, что счёт необязателен, и ваша единственная защита — запись, которую ни один из вас не может отредактировать.

Установите GitHub App Timestamp GIT на свои клиентские репозитории, дайте ночному анкорингу работать и приложите сертификат к следующему счёту. Это занимает около десяти минут один раз и меняет тон каждого последующего разговора о сдаче работы.

Похожие статьи

• Доказательство метки времени Git-коммита для патентных споров
• Как проверить метку времени Биткоина для Git-репозитория
• Автоматическое проставление меток времени Git: как GitHub App привязывает каждый коммит