ProofLedger publica verificación offline de artefactos y señala el fail-open

ProofLedger, el proyecto que ancla el hash SHA-256 de un archivo en Polygon y Bitcoin, ha sacado verify-proof, un paquete de Python que recompone la prueba en local y la valida sin llamar a su API. Lo acompaña una GitHub Action para CI. El autor cuenta que casi todo lo que hizo mal mientras construía el sistema estaba en el lado de la verificación, no en el del anclaje, y de ahí sale el argumento.

Qué contacta el verificador cuando sale verde

La pregunta útil no es qué verifica la comprobación, sino a quién contacta. Esa lista de hostnames es la frontera de confianza real del montaje, y suele ser más corta de lo que la gente cree y apuntar a más terceros de los que espera.

La afirmación se descompone en tres partes con modos de fallo distintos. La primera es local y barata: los bytes del archivo dan ese hash, sin red, sin autenticación y sin proveedor. La segunda es de estructura de datos: o la prueba que tienes trae material suficiente para recomponer el compromiso, o hay que ir a preguntar. La tercera, que el compromiso sea real y se pueda saber sin que lo diga quien lo emitió, es donde las dos anteriores dejan de sostenerte.

Un digest correcto y un compromiso recomponible se cumplen aunque ese compromiso no exista en ningún sitio salvo la base de datos del emisor. Que el check pase en CI sólo dice que las dependencias del verificador respondían y devolvían algo que al verificador le gustó.

Verde no es lo mismo que correcto

Hay dos trampas. La primera es el fail-open: si el verificador trata un lookup inalcanzable como aviso blando en vez de fallo duro, un check verde y un endpoint muerto se ven igual desde fuera, y no te enteras porque lo que vigilas es la ausencia de rojo. La segunda es más fina. Si la única forma de responder a la tercera parte es una llamada HTTPS a la API del emisor que devuelve un {"valid": true}, eso no es verificación, es la palabra del emisor reescrita en JSON con TLS por encima. Si el emisor es además quien emite la afirmación que se comprueba, hay un bucle.

Una prueba es autocontenida cuando se puede ir del archivo en disco al compromiso anclado usando sólo el material de la prueba más una consulta a algo público. Si los hashes se agruparon en lote hace falta una ruta de inclusión: la prueba entrega los hashes hermanos hasta la raíz, se concatenan y se hashean paso a paso, y o se llega a la raíz registrada o no. Nada de eso necesita un servidor. Lo que no se puede derivar en local es la raíz que está en la cadena, y ésa es la única consulta; debería apuntar a una cadena pública, no al emisor.

El propio autor pone límites. La verificación offline no inventa estado de cadena: hay que haber obtenido la raíz anclada en algún momento, de un nodo propio, de un explorador o de una copia fijada. Mueve la confianza de la API del proveedor en caliente al registro en cadena que cualquiera puede comprobar, lo cual es una mejora real y no magia. Un timestamp prueba que los bytes existían antes de cierto momento y nada más. Y no reclama que su prueba en Bitcoin sea mejor que una gratis: OpenTimestamps da sellado en Bitcoin sin coste y el resultado es criptográficamente igual de válido. El anclaje en Polygon es gratis e ilimitado en todos los planes, incluido el gratuito.

Hay además un endpoint REST público sin autenticación para que un auditor lo consulte por su cuenta, limitado a 120 peticiones por hora e IP: sirve para que una persona compruebe un dato, no para montar una flota de CI encima.

Lo que queda por ver es cuánta gente revisa la rama de código donde falla la llamada HTTP. Si registra y continúa en lugar de lanzar excepción, el verde que llevan meses viendo no significa lo que creen.