#dusk $DUSK @Dusk
En los sistemas financieros tradicionales, para evitar que una misma orden se procese dos veces, se recurre a un mecanismo especialmente sencillo: el número de secuencia o el número de cheque. Cada orden lleva un identificador único; el sistema solo reconoce la primera presentación y rechaza cualquier reenvío duplicado. Es un enfoque algo tosco, pero durante décadas la infraestructura financiera se ha apoyado en este “método rústico”, evitando la gran mayoría de los incidentes por cobros o liquidaciones duplicadas.

En el modelo de cuentas Moonlight de Dusk se hace lo mismo: cada cuenta mantiene un nonce (un contador). Cada transacción debe tener el nonce exactamente una cifra mayor que el actual. Después de enviarse, el nonce se incrementa. Así, incluso si la misma transacción firmada se difunde o se envía de nuevo, la red solo aceptará la primera vez; las posteriores serán rechazadas directamente. Suena como un diseño tan básico que muchos quizá ni se fijan en que existe, pero precisamente esos mecanismos fundamentales determinan si una cadena puede confiarse para procesar instrucciones de liquidación reales, con dinero de verdad.

A lo largo de estos años en el sector, he visto más de una ocasión en que, por un mal manejo de órdenes duplicadas en sistemas antiguos, una misma transferencia terminó cobrando dos veces, y luego hubo que pasar por largos procesos de conciliación y reembolso. En la finanza tradicional, estos problemas suelen clasificarse como “incidentes operativos”; rara vez aparecen en las noticias, pero para la institución implicada y sus clientes no es nada fácil gestionarlos. Si una cadena que pretende servir a la liquidación de instituciones no implementa bien incluso este mecanismo de protección antirrep. (anti-replay) más básico, entonces por muchas pruebas de conocimiento cero que amontone después, no servirá de mucho: a las instituciones no les importa lo avanzada que sea su criptografía; lo primero que preguntan es: “¿Mi dinero se cobrará dos veces?”

Este diseño no es nada sexy al hablarlo, no hay nada que merezca capturas y tuits, pero precisamente que tan bien o mal esté implementado este tipo de mecanismo básico es, para mí, el punto de partida para juzgar si la base de una cadena es sólida, no el final.

¿Crees que, para evaluar si una cadena es confiable o no, conviene empezar por estos mecanismos básicos y sencillos, o primero mirar cuántas tecnologías nuevas y “dichosas” tiene?