Logo após o começo do Outono, um velho conhecido meu que trabalha com um sistema de trading de alta frequência veio de Shenzhen a Pequim a trabalho e me chamou para beber uma cerveja artesanal em Sanlitun. Antes disso, ele passou oito anos nas finanças tradicionais. No ano passado, mudou para um market maker de cripto, cuidando da arquitetura de base do sistema de negociação. Depois de três copos de IPA, finalmente conseguiu tirar do barril os meses de espera que tinha acumulado.
“Você sabe, quando eu trabalhava em uma bolsa tradicional, o preço passava pelo gateway, ia para o engine de estratégia e depois jorrava até chegar às ordens — e a latência de ponta a ponta era controlada em cinquenta microssegundos. Cinquenta microssegundos. Com o que sustentávamos isso? Memória compartilhada, bypass do kernel, aceleração de hardware em FPGA. Uma camada pressionando a próxima. Chegando nesse lado de cripto, eu me agachei e fui puxando para ver por dentro: descobri que muitos protocolos ainda estavam usando polling via HTTP como espinha dorsal.”
Ele largou a xícara na mesa; no olhar dele não era raiva, era aquela sensação absurda de quem já ficou confuso por muito tempo e finalmente não aguentou mais: “HTTP polling. De vez em quando você levanta a cabeça e pergunta uma coisa tipo ‘tem dados aí?’. Se não tiver, você fica rodando em vazio, aí depois vai bater de novo na porta. Isso não é o mesmo truque de vinte anos atrás, de ficar刷网页? Vocês chamam isso de ‘infraestrutura para finanças descentralizadas’?”
Fiquei sem palavras com o que ele disse. Ele estava falando a verdade. Nos últimos anos, a camada de consenso do blockchain avançou como se tivesse combustível de foguete — PoW virou PoS, uma única cadeia virou modularizada, e daqueles poucos milhares de TPS se chegou a milhares. Mas a camada de comunicação de rede que fica por baixo do consenso basicamente permaneceu onde estava, sem mexer. Entre os nós, ou é gossip broadcast espalhando para todo lado, ou é JSON-RPC furando uma interface a cada poucos segundos. Broadcast tem redundância; polling fica em vazio; a latência não se mantém estável — ela vai e vem; quando o throughput chega num gargalo, ela começa a “arder”; e quando a rede treme, o tempo de resposta inteiro do sistema vira quase uma ciência mística.
@NewtonProtocol No capítulo 5.4 do whitepaper, o título é “Streaming Two-Phase Consensus”, consenso em duas fases com streaming. Eu já tinha escrito um artigo para isso antes, mas na época meus olhos estavam presos àquela filosofia de projeto centrada no consenso pela mediana e no “assíncrono, sem esperar”. Recentemente reli e, de repente, percebi que tinha deixado passar uma decisão técnica ainda mais de base — aquela que encaixa a espinha dorsal do NATS na camada central de comunicação do protocolo.
O texto original do whitepaper diz assim: “The Gateway orchestrates the authorization flow via NATS streaming messaging, enabling sub-second consensus with non-blocking operator communication.” NATS. Essas duas palavras quase não aparecem ao longo de todo o whitepaper, mas o peso técnico por baixo delas — provavelmente é o alicerce mais subestimado no arcabouço inteiro do Newton.
O que é NATS? Quebrando em pedaços: é um middleware de mensagens open source, que nasceu para fazer o trabalho de mensageiro de sistemas distribuídos. Diferente de HTTP polling de cara colada no chão, o NATS não faz aquela coisa de “o cliente vem a cada alguns segundos bater na janela pra perguntar se tem notícia”. É push, não pull. O publicador joga a mensagem em um tópico; todos os assinantes que ficam de olho nesse tópico recebem, no mesmo segundo, empurrada direto na cara. No exato momento em que a mensagem explode, em milissegundos, todas as pessoas que precisam saber já sabem.
O whitepaper continua descrevendo exatamente o que o NATS faz no consenso em streaming do Newton. Na fase Prepare, o Gateway usa NATS para disparar pedidos de captura de dados para todos os operadores como se fosse uma saraivada. Cada operador roda o WASM em seu próprio sandbox, sai para buscar e puxar dados externos, pega as assinaturas ECDSA e as provas, e então empurra o resultado de volta para o Gateway via streaming do NATS. O ponto crucial está nessas duas palavras: “streaming”. O whitepaper escreve, preto no branco: “Operators stream responses back as they complete — there is no synchronization barrier.” Sem barreira de sincronização: quem termina primeiro joga para fora primeiro. Não espera, não enfileira, não fica mudando o rosto de acordo com o dos outros.
O mesmo vale quando você coloca HTTP polling lado a lado: a diferença é tão grande quanto rádio comunicador versus escrever carta. Polling é você, de tempos em tempos, escrever uma carta perguntando “já está?”; do outro lado respondem “ainda não”; aí você espera um pouco mais e escreve outra carta. NATS é quando você liga o walkie-talkie: todo mundo fica no mesmo canal. Quem quiser falar aperta o botão; e a voz explode ao mesmo tempo na orelha de todo mundo. A latência vai de nível de segundos para nível de milissegundos; o throughput sai de dezenas de requisições por segundo para dezenas de centenas de milhares de mensagens por segundo. A base física mudou; só assim o prédio de cima consegue ser erguido.
Neste trecho, o whitepaper não detalha as “partes íntimas” técnicas do NATS. Mas, se você consultar a documentação oficial do NATS, verá que isso nasceu justamente para substituir RabbitMQ, Kafka e outras filas de mensagens tradicionais — escolhendo a dedo exatamente aqueles cenários em que você sente arrepios quando a latência é sensível. A doutrina central do NATS é só quatro palavras — “fire and forget”: você envia e depois esquece. Ele não promete que a mensagem vai necessariamente acabar gravada em disco, nem promete que jamais vai se perder; mas ele usa o próprio “eu” para prometer uma coisa: rapidez. Rápido a ponto de nem dar tempo de piscar. Em um único nó, em um segundo ele cospe mais de dezenas de milhões de mensagens pela boca; e a latência fim a fim consegue chegar à escala de microssegundos. É exatamente essa ordem de grandeza de desempenho de comunicação que sustenta a promessa do whitepaper: “sub-second consensus”. Com uma base de polling, só esperar o handshake do HTTP já é o suficiente para dar uma cochilada. A base física mudou; só aí é possível construir o prédio por cima.
Então por que quase ninguém discute NATS na indústria de criptografia? Porque não é “coisa de narrativa on-chain”. Desenvolvedores de blockchain estão acostumados a enfiar toda lógica em contratos inteligentes, todo estado ser mastigado uma a uma pelo mecanismo de consenso, e toda comunicação seguir aquele padrão de broadcast P2P. Middleware é um conceito que nasceu depois de décadas de tentativa e erro nos sistemas distribuídos tradicionais; no mundo do blockchain, ele sempre foi uma área cega que ninguém tem paciência nem para olhar. Mas os designers do Newton obviamente estavam atentos a uma coisa: consenso é lento; autorização precisa ser rápida. Você não pode esperar um bloco firmar na cadeia para só então julgar se aquela transação deve ou não ser colocada — quando isso acontecer, a transação já teria rodado oito ruas pela cadeia. Você precisa executar todos os julgamentos de conformidade naquele intervalo estreito em que a transação acaba de “saltar”, ainda não tocou o limiar da cadeia. Essa janela não dá para resolver com consenso de bloco, não dá para resolver com HTTP polling, nem com gossip broadcast. Só dá para resolver com mensagens em streaming.
$NEWT Qual posição o token fica nessa tubulação? Volte àquela modelagem de taxas do capítulo 10.1 do whitepaper. As taxas se prendem ao número de instruções do WASM, à quantidade de chamadas de consulta de dados e ao cálculo do consumo de largura de banda. O que é que as mensagens em streaming do NATS “mastigam”? É a largura de banda. Cada prova ECDSA que cada operador devolve na fase Prepare, o pacote de dados de consenso que é enfiado na boca na fase Evaluate, cada mensagem que voa entre os nós durante a agregação de assinaturas BLS — tudo isso circula pelos canos do NATS. Quanto maior o volume de execução, maior o volume de mensagens; e quanto maior a pancada, mais a largura de banda é “engolida”, mais frequente fica a cobrança. Mas as características do NATS, que por natureza devoram throughput sem nem piscar, fazem o custo unitário dessas transmissões cair a níveis tão baixos que sustentam a execução de estratégias de alta frequência, sem estourar o preço a ponto de virar fortuna. Esse é um pré-requisito que a economia de tokens precisa para rodar de forma estável e que todo mundo finge não ter visto: a eficiência da camada de comunicação, com a mão diretamente apertando o gargalo do custo da camada de execução. Se embaixo, na camada de comunicação, estiver o HTTP polling, o gasto de mensagens indo e voltando dentro de uma única execução de estratégia talvez seja até mais “quente” do que a própria computação; com um modelo de cobrança por volume de execução, mal dá alguns dias e ele se desfaz.
De repente eu entendi uma coisa. Por que o Newton cravou com força essa posição de “camada de autorização” e não afundou na lama da “camada de protocolo on-chain”? A camada de comunicação dos protocolos on-chain é cravada na parede pelos pregos do mecanismo de consenso — você só pode usar gossip, ou broadcast P2P; as possibilidades de ajuste de latência e throughput já ficam travadas antes mesmo de nascer. Já a camada de comunicação da autorização está com a mão solta: dá para escolher, na prateleira, a melhor faca para usar. NATS é uma dessas facas velhas, de sistema distribuído tradicional, que passou vinte anos moendo numa rebarba e ajustando o fio; já foi afiada, já foi usada com sangue — corta o que for que corta, é um golpe só. O Newton não precisa se agachar numa forjaria para reinventar uma lâmina: ele só precisa encaixar NATS no seu fluxo de consenso em duas fases. A comunicação entre operadores sai do modo “polling” e é torcida para “push”, e a velocidade de resposta da rede inteira sobe, como se alguém tivesse dado um tranco num degrau.
Meu velho colega ouviu em silêncio enquanto eu falava toda aquela ladainha. Ele ficou com a xícara erguida no ar por alguns segundos e, então, largou uma frase que eu lembro até hoje: “Finanças tradicionais tropeçaram por trinta anos até entender uma coisa — o ponto crítico do sistema de transações não está na computação; está na comunicação. Essas pessoas da criptografia ainda estão agachadas na primeira camada, com a boca só falando de TPS. Ninguém liga para saber como uma mensagem sobe de um nó e vai parar em outro.” #Newt
O Newton se importou. E ele usou NATS. Essa escolha tecnológica, fora do meio técnico, provavelmente nem faz “chover” nenhuma reação; mas quase certamente é o verdadeiro lastro físico que permitiu ao Newton imprimir aquelas cinco palavras — “sub-second consensus” — no papel. Sem essa camada de tubulação por baixo, mesmo que a camada de cima, o motor de estratégias, seja bonito, não passa de um supercarro parado na lama.
Faça sua própria pesquisa. Da próxima vez que você for analisar um conjunto de infraestrutura básica de blockchain, não prenda só seus olhos naquelas duas linhas de TPS e taxa de Gas. Vá mais fundo, desça mais um nível: observe a camada de comunicação — é polling ou push? É o HTTP esbarrando e indo e voltando na sua mão, ou um sistema de middleware de mensagens lá embaixo, silenciosamente, aguentando o fluxo de todo o “monte” por conta própria. Mesmo que sua transação rode enlouquecida na cadeia, se entre os nós ainda rola um “espera aí, vou perguntar de novo” de lógica velha, com vinte anos de atraso, o teto do sistema já foi soldado no lugar bem antes de ele nascer.