#sxt $SXT @SpaceandTime Hay una pregunta que creo que es muy fácil pasar por alto con una frase como «datos verificables»: los contratos inteligentes solo pueden ver el estado en cadena. ¿Por qué habrían de confiar en el resultado de una consulta procedente de una base de datos fuera de la cadena? Las pruebas de conocimiento cero parecen la respuesta, pero la mayoría no tiene claro qué es exactamente lo que demuestran.
Al principio pensaba que la respuesta estaba principalmente en Proof of SQL. Pero, después de estudiar los nodos indexadores, los compromisos de los validadores y el proceso de generación de pruebas de Space and Time, descubrí que la clave está en convertir primero los datos en «objetos comprometidos». El indexador recopila datos de distintas cadenas y los decodifica en tablas; el validador genera compromisos criptográficos sobre el estado de esos datos y los firma mediante un esquema de umbral. Después, quienquiera que haga una consulta debe vincular el resultado a ese compromiso: si los datos se modificaron a escondidas antes de la consulta, la prueba no se verificará.
Este paso es fundamental. Space and Time no enseña a los contratos inteligentes a consultar bases de datos, sino que convierte la «ejecución de consultas» en un cálculo verificable. El probador ejecuta SQL fuera de la cadena y genera una prueba ZK; el contrato solo tiene que verificar el compromiso y la prueba, sin necesidad de confiar en el probador. Lo mismo ocurre con los agentes de IA: las dependencias de datos en las que se basan sus decisiones pueden auditarse.
Así que, a mi juicio, lo que Space and Time resuelve de verdad no es «darle una base de datos a la cadena de bloques», sino transformar los cálculos fuera de la cadena en compromisos que puedan verificarse en ella. El coste también es evidente: si los datos indexados están incompletos, si el compromiso no abarca la instantánea correcta o si la generación de pruebas no alcanza la latencia requerida, cualquier fallo en la cadena reduce la fiabilidad de la «verificabilidad». En particular, Proof of SQL solo demuestra que «la consulta se ejecutó fielmente», no que los datos originales sean verdaderos: basura entra, basura sale.
Lo que más vale la pena observar a largo plazo en Space and Time no es si puede demostrar que una consulta SQL concreta no se manipuló, sino si esta cadena de «compromiso de datos → consulta verificable → consumo por contratos» puede funcionar de forma rápida y estable con cargas reales. La IA y DeFi no necesitan solo criptografía elegante, sino una ingeniería en la que ningún eslabón falle.
Al principio pensaba que la respuesta estaba principalmente en Proof of SQL. Pero, después de estudiar los nodos indexadores, los compromisos de los validadores y el proceso de generación de pruebas de Space and Time, descubrí que la clave está en convertir primero los datos en «objetos comprometidos». El indexador recopila datos de distintas cadenas y los decodifica en tablas; el validador genera compromisos criptográficos sobre el estado de esos datos y los firma mediante un esquema de umbral. Después, quienquiera que haga una consulta debe vincular el resultado a ese compromiso: si los datos se modificaron a escondidas antes de la consulta, la prueba no se verificará.
Este paso es fundamental. Space and Time no enseña a los contratos inteligentes a consultar bases de datos, sino que convierte la «ejecución de consultas» en un cálculo verificable. El probador ejecuta SQL fuera de la cadena y genera una prueba ZK; el contrato solo tiene que verificar el compromiso y la prueba, sin necesidad de confiar en el probador. Lo mismo ocurre con los agentes de IA: las dependencias de datos en las que se basan sus decisiones pueden auditarse.
Así que, a mi juicio, lo que Space and Time resuelve de verdad no es «darle una base de datos a la cadena de bloques», sino transformar los cálculos fuera de la cadena en compromisos que puedan verificarse en ella. El coste también es evidente: si los datos indexados están incompletos, si el compromiso no abarca la instantánea correcta o si la generación de pruebas no alcanza la latencia requerida, cualquier fallo en la cadena reduce la fiabilidad de la «verificabilidad». En particular, Proof of SQL solo demuestra que «la consulta se ejecutó fielmente», no que los datos originales sean verdaderos: basura entra, basura sale.
Lo que más vale la pena observar a largo plazo en Space and Time no es si puede demostrar que una consulta SQL concreta no se manipuló, sino si esta cadena de «compromiso de datos → consulta verificable → consumo por contratos» puede funcionar de forma rápida y estable con cargas reales. La IA y DeFi no necesitan solo criptografía elegante, sino una ingeniería en la que ningún eslabón falle.