La semana pasada, me quedé atascado en una pregunta pequeña sobre la prueba en cripto.
Antes de preguntar si la prueba se puede verificar, ¿cómo saber que sigue siendo la prueba original correcta?
Unos días después, al leer la sección del ejemplo de zkTLS en Twitter/X en la documentación de Newton Protocol, me detuve en el detalle de proofCid.
Al principio, pensé que el CID solo era una dirección para almacenar la prueba.
Se genera una prueba de zkTLS. El cliente guarda esa prueba. El gateway devuelve proofCid. Luego, la tarea usa este CID para que los operadores sepan qué prueba deben obtener al ejecutar la evaluación de políticas.
A simple vista, parece un paso bastante normal de guardado de archivos.
Pero cuanto más lo leo con atención, más veo que @NewtonProtocol no solo está preguntando dónde está la prueba.
Está preguntando si el contenido detrás de esa dirección es realmente la prueba que el cliente creó.
Ese es el punto en el que el CID es diferente a una URL normal.
La URL normalmente dice dónde se puede encontrar el contenido.
El CID dice algo más fuerte: ¿cómo es el hash de este contenido?
Si el contenido cambia, el CID también debe cambiar. Por lo tanto, un proofCid no es solo un puntero. Es un compromiso con los bytes que están detrás de ese puntero.
Pero, en el flujo de autorización, solo recibir un CID desde el Gateway y confiar ciegamente aún no es suficiente.
El ejemplo de Newton no se detiene en recibir proofCid. Cuando recupera los bytes de la prueba, el cliente verifica que los bytes devueltos coincidan con el multihash del CID. Después de store(), el SDK vuelve a derivar el CID a partir de los bytes enviados y rechaza si la respuesta del Gateway no coincide.
Este detalle es pequeño, pero abre un límite (boundary) muy importante.
Newton no deja que proofCid se convierta en una promesa del Gateway.
Que devuelva esa promesa para contrastarla con los bytes reales.
Por eso, el cliente no externaliza por completo la confianza en el Gateway ni en la capa de almacenamiento cuando la evidencia se introduce en la ruta de autorización. La verifica, no por una sensación de confianza, sino contrastando el CID con el propio contenido.
Esta es la parte que me parece interesante.
Una prueba zkTLS puede ser correcta. Una policy puede escribirse bien. Una tarea puede verse válida. Pero si hay una desviación en el traspaso entre la creación de la prueba y la evaluación de la policy, si proofCid apunta a bytes distintos a la prueba original, entonces el sistema está evaluando una evidencia equivocada.
El error en ese momento no está en la criptografía de la prueba.
Está en el límite del almacenamiento de la evidencia.
El Protocolo Newton parece estar intentando bloquear ese error en el límite del cliente. Antes de que la prueba se ponga en una tarea, antes de que los operadores la usen, antes de que la policy se base en ella, el cliente debe asegurarse de que la dirección y el contenido realmente coinciden.
Visto desde ese ángulo, el Límite de Integridad del CID no es solo un asunto de almacenar la prueba para conveniencia.
Es la forma de mantener la evidencia a salvo de manipulaciones a lo largo del trayecto desde que se crea hasta que se usa para autorizar.
Por supuesto, la integridad del CID no resuelve todo.
No prueba que el claim dentro de la prueba sea bueno. No sustituye a la policy. Tampoco garantiza que la fuente de datos externa siempre sea confiable.
Pero protege algo muy concreto: que la prueba se guarda, se recupera y se introduce en la tarea sin que se cambie el contenido detrás de la dirección.
Para mí, este es un detalle pequeño pero llamativo en Newton.
La autorización no solo necesita cumplir la regla correcta.
No hace falta que sea evidencia correcta.
Y antes de que la evidencia se considere confiable, el sistema debe estar seguro de que esa evidencia es realmente lo que el usuario/cliente creó.
Quizá proofCid no debería considerarse como un enlace a la prueba.
Debería considerarse como una promesa de que la prueba detrás de ese enlace no ha sido alterada.