#sxt $SXT @SpaceandTime Una dirección pidió tres préstamos en Ethereum y los devolvió a tiempo; en otra cadena fue liquidada una vez; y en un tercer protocolo ha mantenido depósitos durante dos años. Estos registros están dispersos entre distintas cadenas y contratos, y cuando un protocolo concede un préstamo solo puede ver el saldo actual: todos los prestatarios son desconocidos y el coeficiente de garantía se aplica por igual.
El crédito en cadena no crece, y el problema no está en los fondos, sino en el crédito. Las finanzas tradicionales fijan los precios basándose en historiales hipotecarios, movimientos de cuentas e historiales de reembolso. Todos esos datos existen en cadena, pero nadie puede reunirlos de forma fiable ni demostrar que el resultado no se ha manipulado.
@SpaceandTime cambia precisamente ese punto de partida: reúne el historial de actividad en múltiples cadenas y protocolos en un registro consultable y verificable —préstamos, reembolsos y liquidaciones anteriores, la recuperación tras una liquidación y los protocolos en los que ha habido actividad sostenida— y, después, transmite el resultado a la cadena mediante pruebas de conocimiento cero, para que el propio contrato lo verifique en lugar de confiar en una interfaz de backend.
Desde el punto de vista técnico, se superponen tres capas: los datos en cadena se registran íntegramente (incluidas las transacciones y los registros de eventos de contratos); el historial de las cadenas EVM se puede consultar directamente con SQL; y Proof of SQL emite una prueba del resultado de la consulta. Para el protocolo, la llamada es similar a una lectura de datos corriente, solo que con una capa adicional de verificabilidad.
El cambio se refleja en los parámetros: los requisitos de garantía, las tasas de interés, los límites de crédito y las listas blancas varían según la conducta demostrada, en lugar de fijarse de manera uniforme mediante votaciones de gobernanza. Las direcciones con un historial de cumplimiento impecable obtienen requisitos de garantía más bajos; a las liquidadas varias veces se les exige un mayor margen de seguridad; y quienes mantienen depósitos a largo plazo reciben límites más amplios. Lo mismo se aplica a la distribución: se calcula según la conducta real, y la lucha contra los ataques Sybil pasa de «adivinar» a «calcular».
La privacidad también es fundamental: la consulta no necesita revelar la identidad del mundo real detrás de una dirección ni hacer público el razonamiento de la gestión de riesgos. Lo que se demuestra es que «el cálculo no se ha manipulado», no que «tus datos quedan expuestos». Para los fondos institucionales, esto último suele marcar la diferencia entre atreverse o no a operar en cadena.
Hay que dejar claros los límites: la verificabilidad resuelve que «los datos y los cálculos no se han manipulado», pero no resuelve si «el historial permite predecir el futuro». La gestión de riesgos sigue requiriendo diseño, pruebas retrospectivas e iteración; la diferencia es que, por fin, se basa en datos de entrada que no pueden modificarse a escondidas.
El crédito nunca ha sido el saldo, sino el tiempo. Para que el crédito en cadena crezca de verdad, el primer paso es hacer que el «historial» sea confiable.
El crédito en cadena no crece, y el problema no está en los fondos, sino en el crédito. Las finanzas tradicionales fijan los precios basándose en historiales hipotecarios, movimientos de cuentas e historiales de reembolso. Todos esos datos existen en cadena, pero nadie puede reunirlos de forma fiable ni demostrar que el resultado no se ha manipulado.
@SpaceandTime cambia precisamente ese punto de partida: reúne el historial de actividad en múltiples cadenas y protocolos en un registro consultable y verificable —préstamos, reembolsos y liquidaciones anteriores, la recuperación tras una liquidación y los protocolos en los que ha habido actividad sostenida— y, después, transmite el resultado a la cadena mediante pruebas de conocimiento cero, para que el propio contrato lo verifique en lugar de confiar en una interfaz de backend.
Desde el punto de vista técnico, se superponen tres capas: los datos en cadena se registran íntegramente (incluidas las transacciones y los registros de eventos de contratos); el historial de las cadenas EVM se puede consultar directamente con SQL; y Proof of SQL emite una prueba del resultado de la consulta. Para el protocolo, la llamada es similar a una lectura de datos corriente, solo que con una capa adicional de verificabilidad.
El cambio se refleja en los parámetros: los requisitos de garantía, las tasas de interés, los límites de crédito y las listas blancas varían según la conducta demostrada, en lugar de fijarse de manera uniforme mediante votaciones de gobernanza. Las direcciones con un historial de cumplimiento impecable obtienen requisitos de garantía más bajos; a las liquidadas varias veces se les exige un mayor margen de seguridad; y quienes mantienen depósitos a largo plazo reciben límites más amplios. Lo mismo se aplica a la distribución: se calcula según la conducta real, y la lucha contra los ataques Sybil pasa de «adivinar» a «calcular».
La privacidad también es fundamental: la consulta no necesita revelar la identidad del mundo real detrás de una dirección ni hacer público el razonamiento de la gestión de riesgos. Lo que se demuestra es que «el cálculo no se ha manipulado», no que «tus datos quedan expuestos». Para los fondos institucionales, esto último suele marcar la diferencia entre atreverse o no a operar en cadena.
Hay que dejar claros los límites: la verificabilidad resuelve que «los datos y los cálculos no se han manipulado», pero no resuelve si «el historial permite predecir el futuro». La gestión de riesgos sigue requiriendo diseño, pruebas retrospectivas e iteración; la diferencia es que, por fin, se basa en datos de entrada que no pueden modificarse a escondidas.
El crédito nunca ha sido el saldo, sino el tiempo. Para que el crédito en cadena crezca de verdad, el primer paso es hacer que el «historial» sea confiable.