Querer demostrar que estás limpio sin entregar la lista de clientes: sí, es posible
Lo más incómodo para una institución que entra en el mercado es que quiere demostrar que está limpia, pero no quiere entregar su lista de clientes. Hoy en día, básicamente hay dos opciones: una es entregar las direcciones y el historial de transacciones a una empresa de análisis on-chain para que les asigne una puntuación, lo que equivale a mostrarle todas tus cartas a un tercero; la otra es crear una lista blanca de Merkle, que solo permite demostrar que una dirección concreta está en el conjunto, pero no que el conjunto en sí esté limpio. En la ruta de datos privados de SXT probé una tercera opción: colocar la lista interna y la lista pública de direcciones restringidas en el mismo conjunto de tablas, de modo que la consulta devuelva un valor booleano junto con una prueba. Así, solo se revela la conclusión, sin divulgar ningún registro. Las posibilidades de este enfoque son mucho mayores de lo que la mayoría cree: se puede usar para pruebas de reservas, para controles de sanciones e incluso para comprobar si los activos de un cliente superan cierto umbral. En todos los casos, solo se comunica una respuesta afirmativa o negativa. La verdadera dificultad técnica está en la vigencia de los datos: las listas cambian a diario y las pruebas deben volver a generarse con ellas; de lo contrario, estarías demostrando que estabas limpio la semana pasada. Ya tropecé una vez con esto: usé una prueba antigua para verificar una lista nueva y el contrato me dijo que todo estaba en orden. En ese momento, se me heló un poco la sangre. Después aprendí a incluir en la prueba el hash de la versión de los datos; si la versión no coincide, se rechaza directamente. El problema no está en la criptografía, sino en la propia lista. Quién la mantiene, con qué frecuencia se actualiza y si se pueden auditar los registros de actualización son cuestiones operativas; da igual que todo lo demás funcione si la lista está llena de errores. Además, todavía no está claro si la ley reconocerá las pruebas criptográficas; los responsables de cumplimiento prefieren ver un informe con sello oficial. En comparación con las pruebas de reservas de Chainlink, este enfoque es más flexible: permite ejecutar cualquier consulta SQL, no solo sumar saldos. El precio es que tienes que asumir por tu cuenta el trabajo de ingeniería necesario para las pruebas. Creo que este camino lo adoptarán primero los proyectos RWA y las instituciones de custodia, porque son quienes más necesitan esa capa que permite demostrar sin revelar. Para profundizar de verdad, también habría que combinar pruebas de rango y pruebas agregadas; por ejemplo, demostrar tanto que la exposición total está por debajo del límite como que ninguna contraparte individual lo supera. Por ahora no hay herramientas listas para eso, así que hay que montarlo todo por cuenta propia. Cuando esta capa funcione bien, también cambiará el discurso de ventas de las instituciones: pasará de «tenemos controles de riesgo muy estrictos» a «puedes verificarlo tú mismo». #sxt $SXT @SpaceandTime
Lo más incómodo para una institución que entra en el mercado es que quiere demostrar que está limpia, pero no quiere entregar su lista de clientes. Hoy en día, básicamente hay dos opciones: una es entregar las direcciones y el historial de transacciones a una empresa de análisis on-chain para que les asigne una puntuación, lo que equivale a mostrarle todas tus cartas a un tercero; la otra es crear una lista blanca de Merkle, que solo permite demostrar que una dirección concreta está en el conjunto, pero no que el conjunto en sí esté limpio. En la ruta de datos privados de SXT probé una tercera opción: colocar la lista interna y la lista pública de direcciones restringidas en el mismo conjunto de tablas, de modo que la consulta devuelva un valor booleano junto con una prueba. Así, solo se revela la conclusión, sin divulgar ningún registro. Las posibilidades de este enfoque son mucho mayores de lo que la mayoría cree: se puede usar para pruebas de reservas, para controles de sanciones e incluso para comprobar si los activos de un cliente superan cierto umbral. En todos los casos, solo se comunica una respuesta afirmativa o negativa. La verdadera dificultad técnica está en la vigencia de los datos: las listas cambian a diario y las pruebas deben volver a generarse con ellas; de lo contrario, estarías demostrando que estabas limpio la semana pasada. Ya tropecé una vez con esto: usé una prueba antigua para verificar una lista nueva y el contrato me dijo que todo estaba en orden. En ese momento, se me heló un poco la sangre. Después aprendí a incluir en la prueba el hash de la versión de los datos; si la versión no coincide, se rechaza directamente. El problema no está en la criptografía, sino en la propia lista. Quién la mantiene, con qué frecuencia se actualiza y si se pueden auditar los registros de actualización son cuestiones operativas; da igual que todo lo demás funcione si la lista está llena de errores. Además, todavía no está claro si la ley reconocerá las pruebas criptográficas; los responsables de cumplimiento prefieren ver un informe con sello oficial. En comparación con las pruebas de reservas de Chainlink, este enfoque es más flexible: permite ejecutar cualquier consulta SQL, no solo sumar saldos. El precio es que tienes que asumir por tu cuenta el trabajo de ingeniería necesario para las pruebas. Creo que este camino lo adoptarán primero los proyectos RWA y las instituciones de custodia, porque son quienes más necesitan esa capa que permite demostrar sin revelar. Para profundizar de verdad, también habría que combinar pruebas de rango y pruebas agregadas; por ejemplo, demostrar tanto que la exposición total está por debajo del límite como que ninguna contraparte individual lo supera. Por ahora no hay herramientas listas para eso, así que hay que montarlo todo por cuenta propia. Cuando esta capa funcione bien, también cambiará el discurso de ventas de las instituciones: pasará de «tenemos controles de riesgo muy estrictos» a «puedes verificarlo tú mismo». #sxt $SXT @SpaceandTime
