Poco después del inicio de la temporada, un viejo colega que trabaja en un sistema de *trading* de alta frecuencia vino de Shenzhen a Beijing por trabajo y me invitó a tomar cerveza artesanal en Sanlitun. Antes había estado ocho años en las finanzas tradicionales. El año pasado se cambió a un *market maker* de cripto y se encargó de la arquitectura de bajo nivel del sistema de trading. Después de tres IPA, por fin se le desbordó la botella de cerveza artesanal: llevaba meses guardando los barriles y los dejó salir a la vez.

"¿Sabes qué? Cuando yo estaba en una bolsa tradicional, el precio pasaba del gateway al motor de estrategias y de ahí al envío de órdenes, y toda la cadena mantenía la latencia controlada en cincuenta microsegundos. Cincuenta microsegundos. ¿Con qué se sostenía eso? Memoria compartida, bypass del núcleo, aceleración por hardware con FPGA: empujando capa por capa hacia abajo. En el mundo cripto me agaché, lo desarmé y eché un vistazo: la mayor parte de los protocolos todavía usan sondeo HTTP como columna vertebral."

Dejó la taza sobre la mesa. En sus ojos no había ira, sino esa sensación absurda de quien lleva tiempo confundido y por fin ya no puede aguantar más: “Sondeo HTTP. Cada cierto tiempo, asomas la cabeza y preguntas ‘¿hay datos?’. Si no, te quedas dando vueltas en vacío y luego vuelves a llamar a la puerta otra vez. ¿Esto no era el mismo truco de hace veinte años para refrescar páginas web? ¿Ustedes le llaman a esto ‘infraestructura para finanzas descentralizadas’?”

Me dejó sin palabras. Dijo la verdad. En los últimos años, la capa de consenso de blockchain ha avanzado como si le hubieran puesto combustible de cohete: PoW pasó a PoS, una sola cadena se volvió modular, y de unos pocos miles de TPS se llegó a miles. Pero debajo de la capa de consenso, la comunicación de red que la soporta, básicamente sigue donde estaba. Entre nodos, o se hace un broadcast masivo con el protocolo gossip, o se perfora la interfaz cada pocos segundos con JSON-RPC. Los broadcasts tienen redundancia; el sondeo tiene “tiempo muerto”; la latencia nunca se mantiene estable; en cuanto el throughput toca el cuello de botella empieza a respirar con dificultad; y cuando la red se sacude, el tiempo de respuesta completo del sistema se vuelve casi magia.

@NewtonProtocol En el capítulo 5.4 del whitepaper, el título es “Streaming Two-Phase Consensus”, consenso en dos fases con streaming. Yo había escrito antes un artículo para esa sección, pero entonces tenía los ojos clavados en esa filosofía de diseño: la de la mediana del consenso y “sin esperar” en lo asíncrono. Recientemente lo releí y, de pronto, me di cuenta de que me había saltado una decisión técnica aún más de base: la forma en que incrusta la columna vertebral de NATS dentro de la capa de comunicación central del protocolo.

El texto original del whitepaper lo dice así: “The Gateway orchestrates the authorization flow via NATS streaming messaging, enabling sub-second consensus with non-blocking operator communication.” NATS. Esos dos términos casi no aparecen en todo el whitepaper, pero el peso técnico que se sienta debajo de ellos podría ser, probablemente, uno de los pilares más subestimados en todo el entramado de Newton.

¿Qué tipo de criatura es NATS? Desglosándolo: es un middleware de mensajería de código abierto, nacido para que los sistemas distribuidos tengan a quién acudir para hacer los recados. A diferencia del sondeo HTTP, que de rodillas pregunta cada pocos segundos si hay mensajes nuevos, NATS no hace “pull”, sino “push”. El publicador lanza el mensaje al tema (topic) y todos los suscriptores mirando ese tema reciben el push en la misma fracción de segundo. En el instante en que el mensaje explota, en el plazo de milisegundos, todos los que deberían saberlo lo saben.

A continuación, el whitepaper describe con claridad las tareas específicas que NATS cumple en el consenso en flujo de Newton. En la fase Prepare, el Gateway usa NATS para disparar solicitudes de extracción de datos a todos los operadores como si fueran perdigones. Los operadores, por su cuenta, ejecutan en su sandbox WASM: salen a buscar datos externos, obtienen la prueba firmada con ECDSA y luego, siguiendo el flujo de NATS, devuelven los resultados al Gateway. Lo importante son esas dos palabras: “en flujo”. El whitepaper lo escribe sin rodeos: “Operators stream responses back as they complete — there is no synchronization barrier.” No hay barrera de sincronización: quien termina primero, entrega primero. No espera, no se ordena, no se mira la cara entre sí.

Comparado con el sondeo HTTP, la diferencia es enorme, como la de una radio y escribir una carta. El sondeo es que escribes una carta cada cierto tiempo y preguntas: “¿ya está?”. Del otro lado te responden: “todavía no”, y luego vuelves a escribir otra carta. NATS es que enciendes la radio, y todos cuelgan en el mismo canal: quien quiera hablar solo aprieta el botón, y su voz explota al mismo tiempo al lado del oído de todos. La latencia, de aplastar en segundos a aplastar en milisegundos; el throughput, de decenas de peticiones por segundo a decenas de cientos de miles de mensajes por segundo. Cambia la base física y entonces la torre de arriba sí se puede construir.

En esta sección, el whitepaper no explica en detalle los “fundamentos técnicos” de NATS. Pero si buscas en la documentación oficial de NATS, verás que esto nació precisamente para reemplazar RabbitMQ, Kafka y otras colas de mensajería tradicionales, afinadas para escenarios en los que la latencia es tan sensible que te pone la piel de gallina. La doctrina central del diseño de NATS son solo cuatro palabras: “fire and forget”. Envías el mensaje y te olvidas. No te garantiza que el mensaje se guarde necesariamente en disco, ni que jamás se pierda; pero lo que sí garantiza con su vida es esto: la velocidad. Una velocidad tan extrema que ni siquiera te da tiempo a parpadear. Un nodo puede escupir decenas de millones de mensajes por segundo, y la latencia de extremo a extremo puede llegar a microsegundos. Justo esa escala de rendimiento de comunicación es lo que hace que el compromiso de “sub-second consensus” del whitepaper sea viable. Si lo cambias por un sondeo, con solo esperar el handshake de HTTP ya podrías dormir tranquilo. Cambia la base física y ya puedes construir la parte de arriba.

Entonces, ¿por qué en la industria cripto casi nadie habla de NATS? Porque no pertenece a la narrativa “on-chain”. Los desarrolladores de blockchain están acostumbrados a meter toda la lógica en los smart contracts, a comerse todo el estado a bocados el motor de consenso, y a que toda la comunicación vaya por esa vía de broadcast P2P. Los middlewares son una idea que salió de sistemas distribuidos tradicionales, después de décadas de prueba y error; en el mundo blockchain han sido siempre una zona ciega que nadie se molesta en mirar. Pero los diseñadores de Newton obviamente tienen algo en mente: el consenso es lento, y la autorización debe ser rápida. No puedes esperar a que un bloque se consolide en la cadena para luego volver atrás y decidir si esa transacción debe subirse o no: para entonces, la transacción ya habrá salido corriendo a ocho calles de distancia dentro de la cadena. Tienes que ejecutar todos los juicios de cumplimiento dentro de esa ventana de tiempo estrecha como una navaja, justo cuando la transacción acaba de salir y todavía no ha cruzado el umbral de la cadena. Esa ventana no se puede resolver con consenso de bloque, no se puede con sondeo HTTP, y tampoco con broadcast tipo gossip. Solo puede resolverse con mensajes en flujo.

$NEWT ¿Qué papel ocupa el token en esta tubería? Vuelve a la sección 10.1 del whitepaper: el modelo de costos. Los costos se desglosan por la cantidad de instrucciones WASM, llamadas a consultas de datos y consumo de ancho de banda. ¿Qué es lo que “masticaría” NATS con sus mensajes en flujo? El ancho de banda. Cada prueba ECDSA que cada operador devuelve en la fase Prepare, los paquetes de datos de consenso que luego se introducen en la fase Evaluate, cada mensaje que salta entre nodos durante la agregación de firmas BLS… todo corre dentro del conducto de NATS. Cuanta más ejecución haya, más mensajes habrá; y cuanto más, más “se lo traga” el ancho de banda, con una facturación cada vez más densa. Pero gracias a la característica nativa de NATS de consumir throughput sin pestañear, el precio unitario de esa transmisión de mensajes se comprime a niveles tan bajos que aguanta la ejecución de estrategias de alta frecuencia sin que los costos exploten hasta convertirse en una cifra astronómica. Esta es la condición previa, invisible para todos aunque todos la vean, para que la economía de tokens pueda ponerse en marcha con estabilidad: la eficiencia de la capa de comunicación, agarrando de forma directa la arteria principal del costo de la capa de ejecución. Si debajo de esa capa lo que hay es sondeo HTTP, el gasto de los mensajes haciendo ida y vuelta en una ejecución de estrategia tal vez sea más candente que el propio cálculo; y con el modelo de cobro por volumen de ejecución, no hay forma de que aguante más de unos días antes de romperse.

De pronto entendí una cosa: por qué Newton se aferra tanto al rol de “capa de autorización” y no se mete de lleno en el charco de “protocolos on-chain”. La capa de comunicación de los protocolos on-chain está clavada a la pared por el mecanismo de consenso: solo puedes usar gossip o broadcast P2P, y el margen para ajustar latencia y throughput está bloqueado desde el “vientre”. En cambio, en la capa de comunicación de la autorización, las manos están sueltas: puedes ir a la estantería y elegir la cuchilla más conveniente. NATS es esa cuchilla vieja de hace veinte años, lijada y afilada por los sistemas distribuidos tradicionales; ya pasó por el cambio de filo y ya fue alimentada con sangre: para cortar, corta en una sola pasada. Newton no necesitó levantarse un herrero para forjar otra cuchilla: solo tenía que insertar NATS en su propio flujo de consenso de dos fases y, entre los operadores, la comunicación pasó de “modo sondeo” a “modo push”. En toda la red, la velocidad de respuesta subió un escalón de golpe.

Mi viejo compañero de la escuela escuchó en silencio toda mi charla. La taza quedó suspendida en el aire durante varios segundos y luego soltó una frase que aún recuerdo: “Las finanzas tradicionales se tropezaron durante treinta años antes de entender una sola cosa: la parte más sensible de un sistema de transacciones no está en el cálculo, está en la comunicación. Ahora esta gente de cripto todavía se queda en la primera capa, con la boca llena de TPS. A nadie le importa cómo sube una noticia desde un nodo hasta el otro.” #Newt

Newton se preocupó. Y además usó NATS. Esta elección tecnológica, fuera de los círculos técnicos, probablemente ni siquiera levanta una ola; pero casi seguro que es la verdadera “base física” con la que Newton pudo estampar en papel las cinco palabras “sub-second consensus”. Sin esa capa de tubería en la base, aunque la capa superior —el motor de estrategias— sea bonita, no deja de ser un superdeportivo atrapado en el barro.

Haz tu propia investigación. La próxima vez que vayas a examinar un conjunto de infraestructura blockchain, no te limites a pegarte a esas dos cifras: TPS y comisiones de gas. Baja un nivel más, mira su capa de comunicación: ¿es un mecanismo de sondeo o de push? ¿Los mensajes llegan y van a trompicones con HTTP, o debajo hay un middleware de mensajería que, sin hacer ruido, aguanta el tráfico de toda una montaña? Da igual que tu transacción corra en la cadena como si estuviera fuera de control: si los nodos tienen que ponerse de acuerdo “espera un momento, déjame preguntar otra vez” con la lógica vieja de hace veinte años, su techo ya se lo soldaron en su sitio antes incluso de que naciera. Esa es una condición previa que todo el mundo finge no ver para que la economía de tokens pueda funcionar de forma estable: la eficiencia de la capa de comunicación, sujetando directamente el cuello del costo de la capa de ejecución. Si justo debajo de la capa de comunicación hay sondeo por HTTP, el gasto de ida y vuelta de los mensajes en una sola ejecución de estrategia podría ser incluso más abrasador que el cálculo en sí. Con el modelo de cobro por cantidad ejecutada, no tardaría ni unos días en desmoronarse.