PaceProof
Verifica registros de atestación firmados con Ed25519 y genera informes de auditoría mediante herramientas MCP.
Documentación
PaceProof
PaceProof verifica registros de atestación de cómputo firmados con Ed25519 de cualquier proveedor y te dice exactamente cuáles son reales.

Un registro con una firma faltante, malformada o manipulada nunca se incorpora a un total "verificado"; se cuenta y se reporta por separado, cada vez, tanto en salida legible para humanos como en salida --json.
PaceProof no firma ni genera atestaciones. Es una capa neutral de solo lectura para ingesta/verificación/reporte/panel sobre registros que ya están firmados en otro lugar. Apúntalo a un directorio, archivo o URL de registros firmados y te dirá, de forma verificable, qué cómputo se ejecutó realmente, por quién, y si la firma de cada registro es válida.
Instalación
paceproof-cli se publica tanto en npm como en PyPI:
npm install -g paceproof-cli
# or
pip install paceproof-cli
Ambos comandos instalan un binario paceproof. paceproof-cli también está disponible como alias en ambos registros si necesitas desambiguarlo de otra herramienta en tu PATH.
Para compilar desde el código fuente en su lugar (útil si contribuyes, o quieres el estado exacto del repositorio en lugar de una versión publicada):
TypeScript (paquete npm, incluye el servidor MCP):
git clone https://github.com/RudrenduPaul/PaceProof.git
cd PaceProof/packages/cli-ts
npm install
npm run build
node dist/bin.js --help
Python (paquete PyPI, reimplementación independiente):
git clone https://github.com/RudrenduPaul/PaceProof.git
cd PaceProof/packages/cli-py
pip install -e .
paceproof --help
Tanto los comandos publicados npm install -g paceproof-cli como pip install paceproof-cli anteriores se ejecutaron recién en un entorno limpio al escribir este README, y la salida de inicio rápido a continuación es salida real de esas instalaciones, no inventada.
Tabla de contenidos
- Características
- Inicio rápido
- Referencia de comandos CLI
- Referencia de la API de biblioteca
- Cómo funciona la verificación
- Comparación
- Qué es PaceProof y por qué existe
- Preguntas frecuentes
- Contribuciones
- Licencia
Inicio rápido
paceproof init
paceproof report ./paceproof-example
paceproof init genera un par de claves Ed25519 de ejemplo nuevo y 7 registros de atestación de ejemplo: 3 firmados válidamente y 4 intencionalmente rotos (un payload manipulado, una firma con clave incorrecta, una firma malformada y una firma faltante) para que verify/report tengan modos de fallo reales que demostrar, no solo un camino feliz.
Salida real de una ejecución real contra el paquete npm publicado:
$ paceproof report ./paceproof-example
PaceProof report -- source: ./paceproof-example
generated at: 2026-08-04T02:54:30.898Z
== VERIFIED ==
records: 3
compute total: 144.50 gpu_hours
== UNVERIFIED (never counted in verified totals above) ==
records: 4
compute total: 1009 gpu_hours
reasons:
- rec-004: signature does not match record contents
- rec-005: signature does not match record contents
- rec-006: signature must decode to 64 bytes, got 4
- rec-007: schema validation failed: (root) must have required property 'signature'
== BY PROVIDER ==
acme-cloud: verified=132 gpu_hours (2 records); unverified_count=0
beta-compute: verified=12.50 gpu_hours (1 records); unverified_count=0
gamma-hpc: verified=(none); unverified_count=2
delta-cloud: verified=(none); unverified_count=2
== BY WORKLOAD TYPE ==
training: verified=128 gpu_hours (1 records); unverified_count=1
inference: verified=12.50 gpu_hours (1 records); unverified_count=1
idle: verified=4 gpu_hours (1 records); unverified_count=1
unknown: verified=(none); unverified_count=1
verify sale con código distinto de cero cuando algún registro falla (código de salida real de una ejecución real: 1, con 4 registros no verificados presentes):
$ paceproof verify ./paceproof-example
Verified: 3
Unverified: 4
FAIL rec-004: signature does not match record contents
FAIL rec-005: signature does not match record contents
FAIL rec-006: signature must decode to 64 bytes, got 4
FAIL rec-007: schema validation failed: (root) must have required property 'signature'
$ echo $?
1

Renderiza un panel desde los mismos datos:
paceproof dashboard ./paceproof-example --out dashboard.html

Tanto la compilación de TypeScript como la de Python se ejecutaron contra paceproof-example para este README, y ambas produjeron los mismos conteos verificados/no verificados y totales mostrados arriba.
Características
- Adaptadores de fuente de datos conectables.
ingestnormaliza entrada arbitraria al esquema canónico a través de una interfazAdapterdocumentada (interfaz de TypeScript, ABC de Python). El adaptadorjsonlincluido lee JSON delimitado por nuevas líneas ya en forma canónica; un adaptador específico de proveedor (por ejemplo, para la exportación nativa de ComputeLedger) implementa la misma interfaz sin tocar el agregador, el renderizador de informes ni el cableado del CLI. - Verificación Ed25519 con separación estricta verificado/no verificado. Cada registro se verifica para validez de esquema y validez de firma. Un registro que falla cualquiera de las dos verificaciones nunca se fusiona silenciosamente en un total verificado: los conteos verificados y no verificados y los totales de cómputo se calculan a partir de conjuntos disjuntos y se muestran lado a lado en cada informe.
- Dos implementaciones independientes con pruebas de paridad. El paquete de TypeScript (npm) y el paquete de Python (PyPI) son implementaciones reales separadas, no un envoltorio de una u otra. Ambos producen salida
report --jsonbyte-idéntica para la misma entrada; un trabajo de CI ejecuta la salida del CLI de TypeScript contra la salida del CLI de Python en un fixture compartido en ambas direcciones y falla la compilación ante cualquier divergencia. - Panel HTML estático autocontenido.
paceproof dashboardrenderiza un único archivo HTML con CSS en línea y sin JavaScript: sin fuentes CDN, sin scripts externos, sin solicitudes remotas de ningún tipo. Actualmente incluye un tema claro limpio; aún no hay un interruptor de modo oscuro. - Servidor MCP para invocación por agentes.
paceproof mcpinicia un servidor del Protocolo de Contexto de Modelo que exponeverify,ingestyreportcomo herramientas invocables, para que un agente orquestador pueda llamar a PaceProof programáticamente en lugar de invocar un CLI orientado a humanos. Los manejadores de herramientas son envoltorios delgados alrededor de las mismas funciones de agregación/informe que el CLI llama, sin reimplementación separada para la ruta MCP. - Endurecido por seguridad por diseño, no como ocurrencia tardía. Los cubos de agregación se construyen con
Object.create(null)para que un campoproviderocompute_unitcontrolado por un atacante como"__proto__"no pueda contaminarObject.prototype. La única llamada de red que PaceProof hace (ingest <url>) está limitada por un tiempo de espera de 30 segundos y un tope de respuesta de 50 MiB, aplicado contra el conteo real de bytes transmitidos en lugar de confiar en un encabezadoContent-Length. Cada campo de esquema lleva una longitud máxima explícita para que la entrada sobredimensionada no pueda agotar la memoria antes de que se ejecute la validación.
Referencia de comandos CLI
Cada tabla a continuación se copia de la salida real de --help del paquete npm publicado paceproof-cli (v0.1.0).
paceproof init [path]
Crea un directorio de ejemplo con un par de claves de muestra y registros de ejemplo firmados válida/inválidamente.
| Argumento | Descripción |
|---|---|
path | Directorio a crear (predeterminado: ./paceproof-example) |
paceproof verify <path>
Verifica firmas Ed25519 en cada registro encontrado en <path>.
| Opción | Descripción |
|---|---|
--json | Emite JSON estructurado en lugar de una tabla legible para humanos |
--adapter <name> | Adaptador a usar para leer la entrada (predeterminado: jsonl) |
paceproof ingest <path-or-url>
Ejecuta un adaptador nombrado sobre la entrada y emite registros normalizados de esquema canónico como JSONL.
| Opción | Descripción |
|---|---|
--adapter <name> | Adaptador a usar (predeterminado: jsonl) |
--out <file> | Escribe la salida JSONL a un archivo en lugar de stdout |
paceproof report <path>
Ingiere y verifica registros en <path>, luego agrega en un informe resumido.
| Opción | Descripción |
|---|---|
--json | Emite JSON estructurado en lugar de una tabla legible para humanos |
--adapter <name> | Adaptador a usar para leer la entrada (predeterminado: jsonl) |
paceproof dashboard <path>
Renderiza un único panel HTML estático autocontenido desde un informe.
| Opción | Descripción |
|---|---|
--out <file> | Ruta del archivo HTML de salida (predeterminado: paceproof-dashboard.html) |
--adapter <name> | Adaptador a usar para leer la entrada (predeterminado: jsonl) |
paceproof mcp
Inicia un servidor MCP que expone verify, ingest y report como herramientas invocables. Solo paquete TypeScript por ahora: ejecutar paceproof mcp desde el paquete de Python imprime un mensaje que apunta al paquete npm y sale con código distinto de cero.
Cada comando admite códigos de salida reales distintos de cero ante fallos o fallos de verificación, y --help en cada subcomando.
Referencia de la API de biblioteca
El paquete npm también exporta sus internos directamente (main/types en package.json apuntan a código de biblioteca real, no solo al punto de entrada del CLI), para cualquiera que construya un adaptador personalizado o integre lógica de verificación en otra herramienta en lugar de invocar el CLI. Esta superficie es solo TypeScript; el paquete de Python expone paceproof como CLI únicamente, sin API de importación documentada.
import { getAdapter, verifyRecords, summarize } from 'paceproof-cli';
import type { Adapter } from 'paceproof-cli';
const records = await getAdapter('jsonl').read('./paceproof-example/records.jsonl');
const outcomes = verifyRecords(records);
const report = summarize(outcomes);
| Exportación | Firma | Qué hace |
|---|---|---|
Adapter | interface Adapter { readonly name: string; read(input: string): Promise<RawRecord[]> } | El punto de extensibilidad descrito arriba. Impleméntalo para normalizar el formato de exportación de un nuevo proveedor en registros canónicos. |
getAdapter(name) | (name: string) => Adapter | Busca un adaptador registrado por nombre (jsonl viene incluido); lanza una excepción si el nombre no está registrado. |
verifyRecord(raw) | (raw: RawRecord) => VerificationOutcome | Valida el esquema y verifica la firma de un solo registro. |
verifyRecords(raws) | (raws: RawRecord[]) => VerificationOutcome[] | Ejecuta verifyRecord sobre un lote. |
summarize(outcomes) | (outcomes: VerificationOutcome[]) => ReportSummary | Agrega resultados de verificación en la misma estructura verificado/no verificado por proveedor/tipo de carga de trabajo que imprime paceproof report --json. |
verifyRecordSignature(record) | (record: AttestationRecord) => SignatureCheckResult | Verifica solo la firma Ed25519 (la validación de esquema es separada), contra la codificación JSON canónica descrita abajo. |
canonicalizeRecord(record) | (record: Record<string, unknown>) => Uint8Array | Produce la codificación de bytes canónica sobre la que se calcula y verifica una firma: claves ordenadas lexicográficamente, UTF-8, sin espacios en blanco insignificantes. |
buildCli() | () => Command | Devuelve la instancia de Command de Commander.js que el CLI publicado ejecuta, si quieres incrustarla o extenderla en lugar de reimplementar el análisis de argumentos. |
No hay un sitio de documentación de API generado por separado (aún no hay compilación de TypeDoc en CI): la tabla anterior es la referencia hasta que exista uno. Cada firma se extrajo directamente de packages/cli-ts/src/ el 2026-08-03, no reconstruida de memoria.
Cómo funciona la verificación
Cada registro de atestación es un objeto JSON validado contra un único JSON Schema canónico (schema/attestation-record.schema.json), el mismo archivo, byte por byte, que tanto el paquete de TypeScript como el de Python incluyen y contra el que validan. Un registro necesita record_id, issued_at, provider, hardware, workload_type, compute_amount, compute_unit, issuer_public_key y signature; cada campo de cadena tiene una longitud máxima explícita para que la entrada malformada o sobredimensionada falle rápido en lugar de analizarse primero y limitarse después.
El campo signature es una firma Ed25519 sobre la codificación JSON canónica de todos los demás campos: claves de objeto ordenadas lexicográficamente, codificación UTF-8, sin espacios en blanco insignificantes, números renderizados sin un + inicial ni ceros finales innecesarios. Ambas implementaciones producen JSON canónico byte-idéntico para el mismo registro, por lo que una firma verificada por una implementación se verifica bajo la otra.
Un registro está "verificado" solo si pasa ambas verificaciones: válido por esquema y válido por firma. Cualquier otra cosa (una firma faltante, una firma que se decodifica a la longitud de bytes incorrecta, una firma que no coincide con el payload, una firma hecha con la clave incorrecta) está "no verificado". Estos dos conjuntos siempre son disjuntos en el código del agregador, no solo en la forma en que un informe los renderiza: los totales de cómputo verificados y no verificados se acumulan en estructuras separadas, y no hay ruta de código que agregue el compute_amount de un registro no verificado a un total verificado. Una herramienta de informes que confunde silenciosamente números "reclamados" y "probados" blanquea afirmaciones no verificables en algo que parece verificado, lo que anula el propósito de un rastro de auditoría.
Comparación
Los conteos de estrellas y las descripciones a continuación se verificaron en vivo contra la lista de la API de GitHub y el README de cada proyecto el 2026-08-03; ninguno está inventado ni reutilizado de memoria.
| Proyecto | Estrellas | Qué hace | Cómo se diferencia de PaceProof |
|---|---|---|---|
| meghabyte/verifiable-training | 10 | Código de investigación de Stanford NeurIPS 2024 ("Optimistic Verifiable Training by Controlling Hardware Nondeterminism") que elimina la no determinismo del hardware para que los entrenamientos reproduzcan pesos byte-idénticos en diferentes GPUs, y luego construye árboles de Merkle sobre los checkpoints para que un verificador los audite. | Prueba que ese entrenamiento específico ocurrió como se afirmó a nivel de pesos, como un prototipo de investigación de generación de atestaciones, no una herramienta de ingesta/verificación/reporte. Sin adaptadores, sin ingesta de registros firmados preexistentes de múltiples proveedores, sin CLI, sin paridad entre lenguajes, sin superficie MCP. |
| skypilot-org/skypilot | 10,441 | Orquestación de cómputo de IA multi-nube y programación consciente de costos en más de 20 nubes, Kubernetes y Slurm. | Visibilidad y programación de costos y utilización, no verificación criptográfica. Nunca verifica una firma ni separa un número "verificado" de uno "reclamado"; no hay ningún formato de registro de atestación involucrado. |
| opencost/opencost | 6,659 | Monitoreo de costos de Kubernetes y nube y visibilidad de asignación (Apache 2.0, originalmente Kubecost). | Misma categoría que SkyPilot: visibilidad de uso y costos sobre datos de facturación y métricas, no atestación criptográfica. Sin verificación Ed25519, sin división verificado/no verificado, sin esquema de registro de atestación. |
| RudrenduPaul/ComputeLedger | 0 | CLI, biblioteca y servidor MCP agnósticos al proveedor para firmar, encadenar hashes y verificar de forma independiente recibos de uso de cómputo (horas de GPU, hardware, tipo de carga de trabajo) con firmas Ed25519 y un libro de contabilidad local a prueba de manipulaciones. | Complementario, no competidor: proyecto hermano del mismo autor, y la mitad de generación de atestaciones de este problema. PaceProof es la mitad de ingesta/verificación/reporte. Apúntalo a registros de ComputeLedger, o de cualquier otra fuente que firme con Ed25519, y reporta lo que verifica. |
Búsquedas más amplias de una herramienta directamente comparable que "ingiera registros de atestación de cómputo firmados de múltiples proveedores, verifique firmas Ed25519 y mantenga totales verificados y no verificados separados" no encontraron nada más que coincidiera con esa combinación específica al 2026-08-03. La categoría adyacente más cercana es la verificación genérica de atestación remota de hardware (por ejemplo, veraison/services, 47 estrellas, evidencia TPM/SEV-SNP/SGX/TDX): un dominio de atestación diferente (estado de arranque/ejecución del hardware, no registros de uso de cómputo) sin esquema de atestación de cómputo, sin modelo de adaptadores y sin informes de horas de cómputo.
Qué es PaceProof y por qué existe
Las afirmaciones de uso de cómputo de laboratorios de IA, proveedores de nube y operadores de infraestructura son cada vez más difíciles de verificar de forma independiente a medida que crece el volumen de discurso relacionado con el cómputo. La carta abierta real "Pacing the Frontier", firmada en julio de 2026 por más de mil empleados de OpenAI, Anthropic, Google DeepMind y Meta pidiendo herramientas verificables para regular el desarrollo de la IA de frontera, es un ejemplo de esa conversación de la industria, citada aquí solo como contexto motivador. PaceProof no está afiliado a ella, no fue construido en respuesta a ninguna solicitud de sus firmantes y no reclama respaldo ni asociación.
Para ser directos sobre lo único que este README necesita dejar sin ambigüedad: no existe un tratado real de "Verified Slowdown", y no existe tal tratado hoy. Esa frase proviene de un escenario especulativo de pronóstico en ai-2027.com, no de ningún acuerdo internacional, ley u organismo regulador real. PaceProof no implementa, hace cumplir ni certifica el cumplimiento de ningún tratado, ley o regulación, porque no existe tal tratado, ley o regulación aplicable a esta herramienta.
Lo que PaceProof realmente es: una capa de informes neutral y criptográficamente verificable sobre los datos de atestación de cómputo que ya tienes. Si tú (o un proveedor con el que trabajas) ya produces registros de atestación firmados, ya sea a través de ComputeLedger, un pipeline de firma personalizado o cualquier otra cosa que emita registros firmados con Ed25519, PaceProof te dice cuáles de esos registros realmente se sostienen criptográficamente y totaliza solo los que lo hacen, separados limpiamente de los que no. Eso es útil hoy para pistas de auditoría internas y transparencia de uso entre proveedores. No es, y no afirma ser, software de cumplimiento para una regulación que no existe.
Preguntas frecuentes
¿Qué es PaceProof y qué lo hace diferente de una herramienta genérica de monitoreo de costos? PaceProof es un CLI de solo lectura y un servidor MCP que verifica firmas Ed25519 en registros de atestación de cómputo y reporta totales con números verificados y no verificados estrictamente separados, nunca fusionados. Las herramientas de visibilidad de costos como SkyPilot u OpenCost reportan lo que un sistema de facturación dice que se usó; PaceProof reporta lo que una firma criptográfica realmente prueba, y marca todo lo demás como no verificado en lugar de contarlo silenciosamente.
¿Proporciona PaceProof cumplimiento legal o regulatorio? No. No existe un tratado real de "Verified Slowdown" ni una regulación comparable con la que PaceProof deba cumplir, y PaceProof no hace ninguna afirmación de cumplimiento de ningún tipo. Verifica firmas Ed25519 en los registros que le das y reporta los resultados. Trata su salida como un informe de verificación criptográfica, no como una certificación legal o regulatoria.
¿Firma o genera PaceProof registros de atestación? No. PaceProof es de solo lectura: ingiere, verifica y reporta sobre registros que ya están firmados en otro lugar. Si necesitas generar registros de atestación de cómputo firmados, eso es una preocupación separada; consulta ComputeLedger, un proyecto hermano del mismo autor, para el lado de la firma.
¿En qué se diferencia PaceProof de ComputeLedger? Son complementarios, no competidores, y construidos por el mismo autor. ComputeLedger firma y encadena hashes de recibos de uso de cómputo; PaceProof ingiere y verifica registros que ya están firmados, de ComputeLedger o de cualquier otra fuente que firme con Ed25519. Si necesitas producir registros firmados, usa ComputeLedger. Si necesitas verificar de forma independiente registros que ya tienes, usa PaceProof.
¿Qué sucede con un registro con una firma incorrecta? ¿Simplemente se descarta?
No. Un registro que falla la validación de esquema o la verificación de firma nunca se descarta ni se excluye silenciosamente. Se cuenta en unverified_count, su cantidad de cómputo se totaliza por separado en unverified_compute_total_by_unit, y la razón específica por la que falló (payload manipulado, clave incorrecta, firma malformada, campo faltante) se reporta junto a él. Nada de un registro fallido desaparece de la salida.
¿Puedo agregar soporte para un proveedor cuyo formato de exportación no sea JSONL?
Sí, para eso está la interfaz de adaptador. Implementa la interfaz Adapter (TypeScript) o el ABC Adapter (Python): un name y un método read(input) que devuelve registros ya normalizados al esquema canónico. No necesitas tocar el agregador, el renderizador de informes ni el cableado existente del CLI más allá de registrar el nombre del nuevo adaptador.
¿Hace paceproof ingest <url> llamadas de red arbitrarias?
Solo la que pides explícitamente. Todos los demás comandos operan sobre archivos locales. ingest <url> es la única llamada de red opcional en toda la herramienta, y está limitada: un tiempo de espera de 30 segundos y un límite de respuesta de 50 MiB aplicado contra el recuento real de bytes transmitidos, no solo un encabezado Content-Length que el servidor remoto podría falsear.
¿Funciona PaceProof en Windows, macOS y Linux? El paquete npm requiere Node.js 18 o superior y no tiene código específico del sistema operativo, por lo que se ejecuta en cualquier lugar donde se ejecute Node, incluidos Windows, macOS y Linux. El paquete Python requiere Python 3.10 o superior y está listado como independiente del sistema operativo en PyPI. Ambos son herramientas puras de espacio de usuario sin dependencias nativas compiladas.
¿Por qué hay dos implementaciones en lugar de un solo CLI con enlaces?
Para que cada paquete sea una cosa real e independiente que puedas instalar desde su registro nativo (npm o PyPI) sin arrastrar un runtime del otro lenguaje. Un archivo JSON Schema compartido y una suite de pruebas de paridad entre lenguajes (ejecutada en ambas direcciones en CI) mantienen su salida report --json idéntica, de modo que la implementación que elijas no cambia lo que obtienes.
¿Está disponible el servidor MCP en el paquete Python?
No actualmente. paceproof mcp es solo TypeScript por ahora: ejecutarlo desde el paquete Python imprime un mensaje que te dirige al paquete npm y sale con código distinto de cero. Todos los demás comandos (init, verify, ingest, report, dashboard) son una implementación Python completa e independiente.
¿Bajo qué licencia está PaceProof y puedo usarlo comercialmente? MIT. Puedes usar, modificar y redistribuir PaceProof comercialmente sin regalías y sin la obligación de abrir el código de tu propio software, sujeto únicamente a mantener el aviso de copyright y el texto de la licencia según los términos de la licencia MIT.
Contribuciones
CI (.github/workflows/ci.yml) ejecuta tres trabajos en cada push y PR a main: lint + typecheck + test de TypeScript, lint (ruff) + typecheck (mypy --strict) + test (pytest) de Python en Python 3.10 y 3.13, y un trabajo de paridad entre lenguajes que compila el CLI de TypeScript, instala el CLI de Python y ejecuta la prueba de paridad de cada lado contra el CLI del otro como subproceso.
Para ejecutar todo localmente:
# TypeScript
cd packages/cli-ts
npm install
npm run lint
npm run typecheck
npm test # 60 tests, Vitest
# Python
cd packages/cli-py
pip install -e ".[dev]"
ruff check src tests
mypy src
pytest -q # 52 tests
Si cambias el esquema, actualiza schema/attestation-record.schema.json en la raíz del repositorio y sus copias en packages/cli-ts/schema/ y packages/cli-py/src/paceproof_cli/schema/, y actualiza la lógica de validación de ambas implementaciones. Una prueba de paridad en la suite de cada paquete verifica su copia local del esquema contra el archivo raíz y hace fallar CI si se desvían.
Consulta ARCHITECTURE.md para conocer el diseño completo del repositorio, las reglas JSON canónicas sobre las que se calcula la firma y cómo encajan la interfaz de adaptador y el servidor MCP.
Licencia
MIT. Consulta LICENSE.