Tenho um hábito que provavelmente me atrasa mais do que deveria. Quando eu leio uma explicação técnica de algo e não consigo entender qual problema ela está realmente resolvendo, eu paro e volto ao começo. Eu me recuso a avançar até o problema ficar claro. Porque, se eu não entender o que está quebrado, não consigo avaliar se a correção realmente funciona.
Então vou fazer isso aqui com o projeto de consenso em duas fases de Newton. Primeiro, o problema. Depois, a solução.
O problema de que ninguém fala o suficiente
Aqui vai algo que eu não considerei com clareza até começar a investigar como realmente funcionam redes de políticas distribuídas. Quando uma transação é verificada com dados em tempo real antes de ser liquidada, essa verificação não está acontecendo contra uma fonte única e limpa de verdade. Ela está acontecendo em uma rede de operadores, e cada um deles pode estar olhando para informações ligeiramente diferentes no mesmo instante.
O que significa “dado em tempo real” na prática? Uma lista de sanções é atualizada. Um endereço de carteira é sinalizado. Um feed de preços dá uma “tick”. Essas atualizações não chegam a cada operador exatamente no mesmo tempo. Um operador pode ter a lista de sanções atualizada dois segundos antes de outro. Um pode estar executando um feed de preços um pouco defasado por causa de um atraso de roteamento em algum lugar na rede.
Agora uma transação chega para avaliação. O Operador A verifica isso com dados que incluem a atualização mais recente das sanções. O Operador B verifica exatamente a mesma transação com dados que ainda não têm essa atualização. Um diz que a transação passa. O outro diz para bloquear. A rede está em desacordo, e ninguém implementou de forma fundamentada uma maneira de resolver isso.
Quero deixar claro uma coisa aqui, porque acho que isso passa despercebido. Isso não é um caso extremo, nem um cenário de pior caso. É a condição normal de qualquer sistema distribuído que trabalha com dados em tempo real. Os dados chegam em momentos diferentes para nós diferentes. É assim que as redes se comportam. A pergunta é se seu sistema foi projetado para lidar com isso de maneira honesta ou se apenas espera silenciosamente que o timing nunca importe.
Por que dados financeiros tornam isso mais difícil
O motivo de eu achar esse problema particularmente desconfortável no contexto da Newton é o que, de fato, é “dado em tempo real”. Não estamos falando de dados em que uma inconsistência de dois segundos seja inofensiva. Estamos falando de listas de sanções, feeds de preços e limites de risco.
Listas de sanções são atualizadas sem aviso. Surge uma nova entidade e, a partir desse momento, qualquer transação envolvendo essa entidade deve ser bloqueada. Se um operador tiver essa atualização e outro não, a mesma transação pode passar de um lado da rede e ser bloqueada do outro. Isso não é um problema técnico. É uma falha de conformidade.
Os feeds de preço mudam rápido. Uma transação que excedeu um limite de risco com base no preço atual pode parecer correta quando comparada a um feed com trinta segundos de atraso. Os números são diferentes. A decisão é diferente. E ninguém fora do sistema consegue dizer qual operador tinha os dados corretos.
Isso foi o que eu continuei encontrando enquanto tentava entender o que o design de duas fases da Newton realmente está resolvendo. Não é só sobre fazer com que os operadores concordem em geral. É sobre fazer com que eles concordem especificamente sobre quais dados estavam usando quando tomaram a decisão. Essa diferença importa enormemente.
O que o consenso de duas fases realmente faz
Quando finalmente entendi o projeto, a lógica pareceu óbvia à retrospectiva. O que geralmente é um sinal de que alguém resolveu algo corretamente.
A Newton divide o processo de avaliação em duas etapas separadas, em vez de executá-lo de uma vez só. A primeira é chamada de fase de Prepare. A segunda é a fase de Evaluate.
Aqui está o que fez “clicar” para mim. A fase de Prepare não avalia nada. Ela apenas concorda. Antes de qualquer operador tocar nas verificações reais de política, a rede chega a um consenso sobre exatamente quais dados cada operador usará para a avaliação. Não dados aproximadamente iguais. Não o que cada operador tiver localmente naquele momento. O mesmo snapshot, acordado e “trancado” antes de a avaliação começar.
Esse único movimento elimina o problema. A inconsistência entre os operadores existia porque cada um estava avaliando com base na sua própria versão local dos dados em tempo real. A fase de Prepare substitui todas essas diferentes visões locais por um único snapshot compartilhado, do qual todo operador na rede concorda.
Então a fase de Evaluate é executada. Cada operador verifica a transação em relação a esse snapshot acordado. Como as entradas são idênticas, os resultados são comparáveis. A rede pode chegar a um consenso real sobre o resultado porque não há mais um desacordo sobre dados por baixo da decisão.
Onde a NATS se encaixa nisso
A coordenação entre os operadores, nas duas fases, ocorre pela NATS. Quando eu me deparei com a NATS nesse contexto pela primeira vez, tive que pesquisar porque eu a associava mais à engenharia de infraestrutura do que a sistemas on-chain. Essa associação está correta. A NATS é um sistema de mensagens construído para ambientes distribuídos de alto desempenho. Ela é usada em serviços financeiros e plataformas de cloud há anos. É rápida, confiável em escala e foi construída exatamente para situações em que muitos nós precisam trocar mensagens com latência mínima.
No design da Newton, a NATS é o canal pelo qual a fase de Prepare passa. Os operadores a usam para estabelecer o snapshot compartilhado dos dados antes de a avaliação começar. A coordenação é rápida o suficiente para não adicionar um atraso significativo ao processo, mas é estruturada de um jeito que a concordância é verificável, e não apenas assumida.
O que eu aprecio nessa escolha é a mesma coisa que eu aprecio na Newton usando Rego para a linguagem de políticas. É uma infraestrutura comprovada, com histórico em sistemas de produção. Ninguém está sendo solicitado a confiar em uma camada de mensagens personalizada que nunca foi submetida a estresse em escala. A NATS tem.
Como isso parece do lado de fora
Do lado de fora, se você só está observando uma transação sendo avaliada, o design de duas fases fica invisível. A transação entra. Um resultado volta. Passa ou é bloqueada.
O que você não consegue ver é que, antes de as verificações de política serem executadas, toda a rede concordou sobre os dados contra os quais essas verificações seriam feitas. Listas de sanções, feeds de preços, parâmetros de risco — tudo isso foi fixado em um único snapshot em todos os operadores participantes. O resultado que retorna não é a visão de um único operador baseada no que ele tinha localmente. É um resultado de consenso baseado em entradas que a rede verificou em conjunto.
Por que esta é a parte que torna a conformidade algo real
Eu continuo voltando a uma única coisa quando penso sobre por que esse design importa além da elegância técnica dele.
Uma verificação de conformidade que pode produzir resultados diferentes dependendo de qual operador a executou não é, de fato, uma verificação de conformidade. É algo mais próximo de um palpite com etapas extras. Se a saída varia com base em qual nó tinha os dados mais recentes, então a saída não significa nada de forma consistente. Você não pode assumir um compromisso regulatório com algo inconsistente.
Ao resolver o problema de acordo sobre os dados antes de a avaliação começar, a Newton faz com que a fase de Evaluate seja algo em que você realmente pode confiar. O resultado significa a mesma coisa, independentemente de qual operador você pergunte, porque todos trabalharam com as mesmas entradas. Essa consistência é o que transforma uma verificação de política pré-estabelecida em um mecanismo real de conformidade, e não apenas numa demonstração de desempenho.
A versão simples
Dois operadores não deveriam conseguir discordar de uma transação porque um tinha uma lista de sanções mais nova do que a outra. A Newton resolve isso fazendo com que os operadores concordem com os dados exatos que usarão antes que qualquer avaliação seja executada. A fase de Prepare “trava” os dados. A fase de Evaluate executa as verificações. A NATS cuida da coordenação entre elas.
O resultado é uma verificação de conformidade consistente em toda a rede, e não apenas consistente com quem conseguiu receber primeiro a atualização mais recente. Em um sistema em que a saída final é uma prova on-chain de que uma transação foi verificada corretamente, essa consistência não é algo “bom de ter”. É tudo.
#SKHynixSaysFundsEyeUpTo$7BInADRs #AsianPCBStockSlideOnNvidiaAIServerDelay #AsianPCBStockSlideOnNvidiaAIServerDelay #Newt $NEWT