Recientemente, al comparar los sistemas tradicionales de valores con la infraestructura en cadena, descubrí que lo primero que preguntan las instituciones no es “qué tan rápido va”, sino: “¿esta cadena puede gestionar, como en el mercado actual, la identidad, los permisos, el libro mayor y la liquidación por separado, y además, cuando sea necesario, unirlos en una cadena completa de evidencia?”. Muchas blockchains públicas son buenas para registrar en un libro mayor abierto, pero no saben responder: ¿quién está autorizado para comprar?, ¿quién no puede transferir?, cuando ocurre un problema, ¿quién puede verificarlo?, y ¿puede el registro alterarse sigilosamente?
@Dusk Lo interesante que me parece es que, desde su diseño inicial, modela los flujos financieros en lugar de hacer primero una plataforma de cómputo genérica y luego encajar complementos de cumplimiento. Identidad y control de acceso, restricciones para emisión de activos, transferencias confidenciales, coexistencia de cuentas públicas y liquidación determinista: estas capacidades se discuten dentro de una misma arquitectura. Para activos sujetos a regulación, esto significa que el emisor no necesita revelar toda la información comercial sensible, y que el regulador o el auditor tampoco tiene que retroceder a formularios fuera de la cadena para realizar la verificación dentro del alcance autorizado.
Me fijo especialmente en que coexistan dos modelos de transacción: uno adecuado para actividades de cuentas públicas y trazables, y otro adecuado para flujos que necesitan ocultar detalles pero a la vez ser verificables. El negocio cotidiano de las instituciones ya es así: las tenencias de los clientes no tienen por qué ser visibles para todos, pero los resultados de la compensación deben ser deterministas; los detalles de las órdenes deben ser confidenciales, pero el estado de la liquidación debe poder consultarse. Incorporar estas dos necesidades en la capa base es más sólido —y más parecido a un mercado real— que construir “módulos de privacidad” distintos en aplicaciones de nivel superior.
Otro problema que suele pasarse por alto es la actualización y el límite de responsabilidades. La liquidación de valores teme más que un simple retraso temporal: teme que se pueda hacer rollback de registros históricos por parte de unos pocos, o que, tras concentrar la altura de nodos clave, la supuesta descentralización pase a depender en la práctica de que unos pocos custodios la ejecuten. Por eso, cuando observo el staking, no miro primero la anualidad, sino la estructura: qué proporción ocupan los nodos principales, la dificultad de entrar para nuevos participantes, si en una actualización hay bifurcaciones anómalas y si la visualización en el navegador y en la cartera es consistente. Todo esto es muy “de ingeniería”, pero en realidad determina si luego se atreverán a colocar activos reales.
Si ya sigues de cerca las finanzas en cadena con enfoque en cumplimiento, mi recomendación es poner el foco en esto: que esta cadena pueda ofrecer, a la vez, confidencialidad, permisos, recibos y finalidades (finalidad/irreversibilidad). $DUSK #dusk
@Dusk Lo interesante que me parece es que, desde su diseño inicial, modela los flujos financieros en lugar de hacer primero una plataforma de cómputo genérica y luego encajar complementos de cumplimiento. Identidad y control de acceso, restricciones para emisión de activos, transferencias confidenciales, coexistencia de cuentas públicas y liquidación determinista: estas capacidades se discuten dentro de una misma arquitectura. Para activos sujetos a regulación, esto significa que el emisor no necesita revelar toda la información comercial sensible, y que el regulador o el auditor tampoco tiene que retroceder a formularios fuera de la cadena para realizar la verificación dentro del alcance autorizado.
Me fijo especialmente en que coexistan dos modelos de transacción: uno adecuado para actividades de cuentas públicas y trazables, y otro adecuado para flujos que necesitan ocultar detalles pero a la vez ser verificables. El negocio cotidiano de las instituciones ya es así: las tenencias de los clientes no tienen por qué ser visibles para todos, pero los resultados de la compensación deben ser deterministas; los detalles de las órdenes deben ser confidenciales, pero el estado de la liquidación debe poder consultarse. Incorporar estas dos necesidades en la capa base es más sólido —y más parecido a un mercado real— que construir “módulos de privacidad” distintos en aplicaciones de nivel superior.
Otro problema que suele pasarse por alto es la actualización y el límite de responsabilidades. La liquidación de valores teme más que un simple retraso temporal: teme que se pueda hacer rollback de registros históricos por parte de unos pocos, o que, tras concentrar la altura de nodos clave, la supuesta descentralización pase a depender en la práctica de que unos pocos custodios la ejecuten. Por eso, cuando observo el staking, no miro primero la anualidad, sino la estructura: qué proporción ocupan los nodos principales, la dificultad de entrar para nuevos participantes, si en una actualización hay bifurcaciones anómalas y si la visualización en el navegador y en la cartera es consistente. Todo esto es muy “de ingeniería”, pero en realidad determina si luego se atreverán a colocar activos reales.
Si ya sigues de cerca las finanzas en cadena con enfoque en cumplimiento, mi recomendación es poner el foco en esto: que esta cadena pueda ofrecer, a la vez, confidencialidad, permisos, recibos y finalidades (finalidad/irreversibilidad). $DUSK #dusk