Computação de uso geral baseada em provas com Magnetar desafia a relação de compromisso dos zkVMs
A Microsoft Research apresentou a computação de uso geral baseada em provas com Magnetar em 15 de outubro, alegando ganhos de velocidade de até 39 vezes em relação a máquinas virtuais de conhecimento zero comparáveis. O sistema pode provar programas escritos em linguagens familiares, mantendo entradas privadas ocultas. Também evita várias suposições criptográficas que projetos concorrentes aceitam para ganhar desempenho.
Essa combinação é relevante porque os sistemas de prova normalmente obrigam desenvolvedores a escolher entre velocidade, generalidade e segurança conservadora. O Magnetar tenta eliminar essa escolha. A Microsoft afirma que ele pode provar programas RISC-V convencionais a milhões de ciclos de processador por segundo, com segurança fundamentada em funções hash padrão.
O adversário imediato não é uma única empresa. É a relação de compromisso de engenharia estabelecida por trás de sistemas como Jolt, SP1 e outros zkVMs de uso geral. Alguns oferecem provas menores, ferramentas maduras para desenvolvedores ou perfis de desempenho diferentes. A alegação do Magnetar é que desenvolvedores não precisam mais aceitar esses compromissos para tornar a computação verificável prática.
A computação de uso geral baseada em provas com Magnetar muda o argumento de desempenho
O Magnetar importa porque combina código convencional, alta capacidade de geração de provas e segurança pós-quântica em um único sistema de pesquisa.
Uma máquina virtual de conhecimento zero, ou zkVM, prova que um programa foi executado corretamente sem exigir que o verificador o execute novamente. Quando o conhecimento zero está ativado, a prova também pode ocultar entradas privadas. Isso fornece ao destinatário evidências sobre um resultado sem revelar os dados confidenciais subjacentes.
A pesquisa sobre Magnetar da Microsoft apresenta o sistema como um avanço em três problemas relacionados. A geração de provas precisa ser rápida o suficiente para cargas de trabalho realistas. Desenvolvedores precisam poder usar programas comuns em vez de circuitos criptográficos construídos manualmente. A segurança subjacente precisa continuar crível durante a vida útil prevista do sistema.
O Magnetar tem como alvo programas compilados para RV64I, o conjunto básico de instruções inteiras RISC-V de 64 bits. O RISC-V oferece ao sistema um modelo de processador convencional e acesso a uma infraestrutura madura de compiladores. Desenvolvedores podem escrever software em Rust, Go ou C, compilá-lo e então provar a execução resultante.
Isso difere de sistemas de prova que exigem que uma aplicação seja reescrita como um circuito aritmético. Um circuito descreve a computação por meio de restrições algébricas que um sistema de prova pode processar. Construir um geralmente exige conhecimento especializado, enquanto mudanças na lógica da aplicação podem demandar trabalho correspondente no circuito.
Um zkVM transfere grande parte dessa carga para o processador virtual. O sistema de prova valida o comportamento do processador instrução por instrução, permitindo que programas usem um caminho de compilação padrão. Os desenvolvedores ainda enfrentam trabalho de integração, mas não precisam expressar cada aplicação como um circuito personalizado.
A Microsoft relata que o Magnetar prova entre 7,2 milhões e 8,7 milhões de ciclos por segundo em um MacBook Pro com M4 Max. O experimento citado utilizou 12 núcleos de desempenho e execuções contendo 2²² ciclos. As provas tinham aproximadamente 600 KiB e levavam entre 11 e 13 milissegundos para serem verificadas.
Uma configuração otimizada supostamente alcança entre 9,5 milhões e 12,8 milhões de ciclos por segundo. A Microsoft afirma que essa melhoria eleva seus ganhos comparativos de velocidade medidos em aproximadamente 1,3 vez. Esses são benchmarks de pesquisa, não medições de serviços em produção.
O artigo técnico que acompanha o anúncio compara o Magnetar com SP1 Hypercube, Jolt-Dory e Jolt-Akita em 15 cargas de trabalho. O conjunto de testes inclui hashing criptográfico, operações em árvores Merkle, assinaturas e transferências de tokens dentro de um pequeno interpretador da Ethereum Virtual Machine.
De acordo com esses resultados, o Magnetar alcançou uma vantagem de capacidade de processamento em média geométrica de cerca de 39 vezes sobre o SP1 Hypercube. As médias relatadas foram de aproximadamente 18 vezes sobre o Jolt-Dory e 9,6 vezes sobre o Jolt-Akita. As comparações individuais variaram substancialmente conforme a carga de trabalho.
Esses números explicam por que o anúncio é mais consequente do que outro benchmark incremental de conhecimento zero. O Magnetar não apenas alega execução mais rápida em um circuito personalizado e restrito. Ele afirma que um sistema de uso geral baseado em hashes pode superar alternativas construídas em torno de componentes criptográficos menos conservadores.
Esse argumento de desempenho ainda tem limites. Os benchmarks foram conduzidos pelo criador do Magnetar em uma configuração de laptop. Ambientes de produção introduzem diferentes limites de memória, padrões de simultaneidade, custos de rede e tamanhos de aplicação. A reprodução independente determinará se a vantagem permanece nessas condições.
Ainda assim, os resultados relatados mudam o ônus da prova. Sistemas baseados em hashes costumam ser considerados conservadores, porém caros. O Magnetar afirma que fundamentos conservadores e velocidade competitiva de geração de provas podem coexistir.
Linguagens padrão aproximam as provas do software comum
A mudança prática não é simplesmente criptografia mais rápida, mas um caminho do código de aplicação mantido até uma execução verificável.
A forma mais simples de entender o zkVM Magnetar é acompanhar um programa por ele. Um desenvolvedor escreve uma aplicação usando uma linguagem compatível e compila essa aplicação para RISC-V. O Magnetar então cria evidências de que a execução resultante do processador seguiu o programa especificado.
O verificador não repete cada instrução. Ele verifica uma prova compacta que representa a correção da execução. A Microsoft afirma que essa verificação leva cerca de 12 milissegundos em sua configuração de benchmark, independentemente da carga de trabalho muito maior representada pela prova.
Isso altera quem pode criar aplicações sustentadas por provas. Circuitos personalizados concentram conhecimento em equipes que entendem tanto a aplicação quanto o sistema de prova. Um zkVM de uso geral permite que engenheiros de software convencionais preservem mais de suas práticas existentes de linguagem, compilador, testes e revisão de código.
A distinção é particularmente importante para softwares que mudam com frequência. Políticas empresariais, pipelines de dados, interpretadores e regras de agentes evoluem ao longo do tempo. Reconstruir circuitos personalizados a cada mudança pode transformar a garantia criptográfica em um gargalo de desenvolvimento.
O Magnetar não faz desaparecer a engenharia de provas. As equipes precisam escolher quais declarações provar, definir entradas públicas e privadas e operar a infraestrutura de geração de provas. Também precisam verificar se o comportamento compilado corresponde à política de alto nível pretendida.
Em vez disso, o sistema desloca a fronteira da especialização. Criptógrafos podem trabalhar no zkVM e em seu mecanismo de provas, enquanto desenvolvedores de aplicações têm como alvo uma arquitetura de processador familiar. Essa divisão se assemelha à relação entre engenheiros de compiladores e programadores de aplicações.
A Microsoft destaca um interpretador da Ethereum Virtual Machine como exemplo. Uma implementação de EVM escrita em Rust ou Go pode ser executada dentro do Magnetar. A construção resultante pode provar execuções de contratos inteligentes existentes sem implementar cada contrato diretamente como um novo circuito de prova.
Essa abordagem é relevante além de blockchains. Uma instituição financeira poderia provar que um programa de processamento de transações aplicou regras específicas sem revelar cada transação. Um serviço de dados poderia provar que aplicou uma transformação acordada a registros privados.
Agentes de IA apresentam outro possível uso. Um agente poderia fornecer evidências de que uma ação passou por um programa de política definido. A prova estabeleceria a execução dessa política, embora não demonstrasse automaticamente que a política era completa ou sensata.
Essa ressalva é essencial. Uma prova confirma uma declaração codificada com precisão. Ela não estabelece que os dados de origem eram precisos, que a política capturava todos os riscos ou que o sistema ao redor não foi comprometido.
A computação baseada em provas, portanto, complementa auditorias, controles de acesso e segurança operacional. Ela não os substitui. Sua contribuição específica é reduzir a confiança necessária para uma computação cujas entradas e programa tenham sido corretamente definidos.
A expressão "Magnetar zkVM explicado" pode soar como um tutorial de produto, mas a notícia importante é arquitetural. A Microsoft argumenta que a execução verificável deve se tornar uma propriedade do software comum respaldada por compiladores, e não uma categoria de aplicação separada.
Essa ambição pressiona todos os projetos de zkVM de uso geral. A experiência do desenvolvedor já não é suficiente se a geração de provas continuar cara. Velocidade bruta também é insuficiente se depender de suposições que compradores esperam substituir mais tarde.
Magnetar vs Jolt expõe a verdadeira relação de compromisso criptográfica
A disputa central não é simplesmente Magnetar vs Jolt em velocidade, mas hashes padrão versus provas menores e suposições alternativas.
O Jolt é uma comparação útil porque os projetos compartilham raízes intelectuais e arquitetônicas. Ambos usam RISC-V para dar suporte a programas de uso geral e se baseiam em pesquisas que tornam instruções de processador e operações de memória menos dispendiosas de provar.
O Jolt usa argumentos de consulta, que permitem a um sistema de prova estabelecer que valores pertencem a tabelas predefinidas. Isso pode representar instruções de processador de modo mais eficiente do que expressar cada instrução por meio de uma grande coleção de restrições de baixo nível.
O repositório do Jolt de código aberto descreve o projeto como um zkVM RISC-V extensível. Também classifica o software atual como alfa e inadequado para uso em produção. Esse aviso ilustra a lacuna mais ampla entre pesquisas de prova promissoras e infraestrutura confiável.
A Microsoft avaliou duas configurações do Jolt. O Jolt-Dory usa suposições de curvas elípticas, enquanto o Jolt-Akita usa criptografia baseada em reticulados. O artigo do Magnetar relata que ambos produzem provas menores que 100 KiB, em comparação com as provas de aproximadamente 600 KiB do Magnetar.
Provas menores podem reduzir custos de armazenamento e transmissão. Essa vantagem importa quando provas atravessam redes restritas ou se acumulam em grande quantidade. O tamanho da prova também pode afetar como um sistema compõe a verificação entre camadas.
O Magnetar aceita a prova maior em troca de uma base de segurança mais restrita. A Microsoft afirma que sua segurança repousa em funções hash padrão, como SHA-256 ou SHA-3. Ele não depende de curvas elípticas, suposições sobre reticulados, hashes algébricos especializados ou uma configuração confiável.
Uma configuração confiável é um processo único que cria parâmetros secretos para alguns sistemas de prova. Se o material secreto for retido ou comprometido, um invasor poderá falsificar provas. Sistemas transparentes evitam essa cerimônia e a carga de governança associada.
Sistemas de curvas elípticas podem fornecer provas compactas e verificação eficiente, mas computadores quânticos suficientemente capazes ameaçariam sua segurança. Sistemas baseados em reticulados são projetados para resistir a ataques quânticos conhecidos, embora dependam de suposições matemáticas diferentes.
A posição do Magnetar é mais conservadora. Funções hash padrão receberam décadas de análise e implantação. Elas também aparecem em todo o software e hardware existentes, o que oferece aos implementadores caminhos de otimização já consolidados.
Isso não torna as funções hash infalíveis. O Magnetar ainda depende de suas propriedades de segurança e da correção de sua implementação. “Pós-quântico” significa resistência a ataques quânticos atualmente conhecidos, não uma garantia permanente contra todas as descobertas futuras.
Ainda assim, há apoio institucional aos designs baseados em hash. O NIST padronizou o SLH-DSA, um esquema de assinatura sem estado baseado em hash derivado do SPHINCS+, na FIPS 205 em 2024. Esse padrão trata de assinaturas digitais, não de zkVMs, mas mostra por que as organizações veem hashes como uma base pós-quântica conservadora.
O SP1 Hypercube oferece outro contraste. O artigo da Microsoft o descreve como “baseado em hash e mais” porque sua estrutura central inclui premissas que vão além da segurança convencional de hashes. As provas medidas do Magnetar foram aproximadamente 4,6 vezes menores que as do SP1 Hypercube, segundo os pesquisadores.
A comparação de desempenho é marcante, mas não deve ser confundida com um ranking completo de produtos. Ferramentas para desenvolvedores, instruções compatíveis, aceleração de hardware, custos de recursão, confiabilidade operacional e integração com o ecossistema influenciam as escolhas de implantação.
Portanto, Magnetar versus Jolt é uma disputa entre pacotes de segurança e engenharia, não entre colunas isoladas de benchmarks. As configurações do Jolt oferecem provas consideravelmente menores. O Magnetar afirma ter maior throughput medido e menos premissas subjacentes.
O resultado pressiona concorrentes a explicarem suas escolhas com mais clareza. Uma equipe que seleciona uma zkVM agora tem motivos para perguntar quais premissas protegem o provador, com que facilidade essas premissas podem mudar e quais custos aparecem fora do throughput de destaque.
BinarySpartan transforma segurança conservadora em velocidade
O mecanismo central do Magnetar alinha computação binária, hashes padrão e verificação recursiva, em vez de tratá-los como problemas separados.
O Magnetar se baseia no BinarySpartan, um sistema de provas que leva o design anterior do Spartan para campos binários. Um campo binário representa valores por meio de aritmética orientada a bits, tornando-se um ambiente natural para a lógica de processadores e funções hash padrão.
O Spartan, apresentado em 2019, forneceu provas de propósito geral sem exigir uma configuração confiável. Ele utilizava um protocolo sum-check, que permite a um verificador checar uma grande computação estruturada por meio de uma troca muito menor de informações algébricas.
Projetos posteriores abordaram diferentes gargalos de desempenho. O Phalanx explorou a estrutura repetida da execução de processadores. O Brakedown desenvolveu uma abordagem rápida de compromissos baseada em hash. Lasso, Twist, Shout e trabalhos relacionados reduziram o custo de provar consultas e operações de memória.
O Magnetar combina essas linhas de pesquisa em vez de depender de uma única invenção isolada. Sua descrição de processador se beneficia da estrutura repetida dos ciclos de instrução. Sua verificação de memória usa técnicas projetadas para leituras e escritas eficientes dentro de uma prova.
O BinarySpartan também funciona com o Ligerito, um esquema de compromisso derivado do Brakedown. Um compromisso permite que um provador se vincule a dados sem revelá-los imediatamente. Mais tarde, o verificador pode checar as aberturas em relação ao valor comprometido.
A troca de anel fornece outro componente. Ela permite que o sistema se comprometa de forma eficiente com vetores de bits enquanto transita entre representações algébricas adequadas a diferentes etapas. A técnica ajuda a conectar rastros de processador à aritmética binária do sistema de provas.
Esses componentes importam porque uma zkVM precisa provar mais do que instruções aritméticas. Ela deve considerar a decodificação de instruções, registradores, consistência de memória, ramificações e a relação entre estados consecutivos da máquina.
Historicamente, a memória tem sido particularmente cara. Uma prova deve mostrar que cada leitura retornou o valor correto escrito anteriormente, sem reproduzir um sistema de memória convencional dentro do verificador. Argumentos de memória eficientes comprimem essa verificação de consistência.
O Magnetar também suporta recursão, ou seja, uma prova pode atestar a verificação de outra prova. Isso permite dividir uma computação longa em partes gerenciáveis e depois combiná-las.
Sistemas de prova recursivos às vezes enfrentam uma incompatibilidade incômoda. A verificação usa operações que a máquina virtual do provador processa de forma ineficiente. Provar o verificador pode então se tornar um custo relevante.
O Magnetar tenta evitar essa incompatibilidade. Seu trabalho de verificação consiste principalmente em avaliação de hashes padrão e aritmética de campos binários. Essas são as mesmas operações que o BinarySpartan foi projetado para provar com eficiência.
O resultado é um tipo de alinhamento arquitetural. O sistema prova o comportamento ordinário de um processador binário, protege compromissos com hashes padrão e pode provar eficientemente seu próprio verificador. Cada camada reforça o mesmo modelo computacional.
A Microsoft afirma que esse design pode suportar computações de comprimento arbitrário ao provar partes e agregá-las. Também aponta registros distribuídos de longa duração e blockchains como possíveis alvos.
Comprimento arbitrário não significa custo constante. Alguém ainda precisa executar a computação e gerar cada segmento de prova. A recursão altera a escala da verificação e da agregação, mas não elimina o trabalho de prova.
O mecanismo explica a velocidade reportada. O Magnetar não acrescenta segurança pós-quântica a um design existente orientado por curvas. Ele organiza o processador, os compromissos, os argumentos de memória e a recursão em torno de operações favoráveis a bits desde o início.
Essa é a parte mais forte do Magnetar zkVM explicada como uma história de engenharia. Suas alegações de velocidade e segurança decorrem da mesma decisão de design, em vez de duas otimizações desconectadas.
Os benchmarks deixam questões importantes sem resposta
O Magnetar mudou a comparação de pesquisa, mas ainda não estabeleceu prontidão para produção nem superioridade universal.
A primeira incerteza diz respeito à validação independente. Os números de desempenho disponíveis vêm da Microsoft Research e de seu artigo técnico. Equipes externas precisam reproduzir esses resultados em hardware, versões de software e entradas de carga de trabalho comparáveis.
A seleção de benchmarks também importa. Quinze aplicações fornecem mais evidências do que um único teste sintético, mas não representam toda carga de trabalho de produção. Programas intensivos em banco de dados, grandes interpretadores, padrões incomuns de memória e serviços sustentados para múltiplos usuários podem revelar gargalos diferentes.
O throughput de ciclos é apenas uma métrica. As equipes também se preocupam com consumo máximo de memória, latência de geração de provas, custos de inicialização, escalabilidade paralela, eficiência na nuvem e recuperação de falhas. Esses fatores podem dominar a economia de um provador implantado.
O tamanho de prova de 600 KiB merece atenção especial. Ele é menor do que a comparação do artigo com o SP1 Hypercube, mas maior do que as provas Jolt reportadas. Aplicações que publicam ou transmitem grandes volumes de provas precisam avaliar essa diferença diretamente.
O suporte a linguagens também exige interpretação cuidadosa. Rust, Go e C podem compilar para RISC-V, mas nem todo recurso de linguagem, biblioteca, chamada de sistema operacional ou comportamento de runtime funciona automaticamente dentro de uma zkVM. Uma linguagem-fonte familiar não equivale a compatibilidade irrestrita.
Desenvolvedores precisam de toolchains documentados, depuradores, suporte a profiling, builds reproduzíveis e relatórios claros de erros. O suporte maduro ao compilador ajuda, mas a zkVM ainda define um ambiente de execução restrito.
A revisão de segurança continua sendo outro requisito. A base do Magnetar pode depender apenas de hashes padrão na camada de premissas criptográficas. A implementação ainda inclui um modelo de processador, código de provas, compiladores, interfaces de host e lógica de aplicação.
Uma falha em qualquer um desses componentes pode produzir uma declaração incorreta ou uma integração explorável. Primitivas conservadoras reduzem uma categoria de risco. Elas não eliminam a garantia de software do plano de implantação.
A alegação de resistência quântica também precisa de formulação precisa. A Microsoft afirma que o Magnetar evita curvas elípticas e depende de funções hash consideradas resistentes a ataques quânticos conhecidos. Algoritmos quânticos ainda podem afetar o nível efetivo de segurança dos hashes, portanto as escolhas de parâmetros devem levar essa redução em conta.
A Microsoft posiciona o Magnetar dentro de um esforço de migração mais amplo. Sua linha do tempo de segurança quântica visa transferir produtos e serviços para criptografia pós-quântica até 2029. O Magnetar se alinha a essa direção, mas o anúncio de pesquisa não o torna um serviço Microsoft implantado.
A disponibilidade comercial é, portanto, uma questão importante em aberto. O anúncio descreve resultados de pesquisa e convida organizações a discutir casos de uso. Ele não fornece data de lançamento para produção, compromisso de nível de serviço ou roteiro amplo de implantação.
A ausência desses detalhes não enfraquece o resultado técnico. Ela altera o que compradores devem inferir dele. Atualmente, o Magnetar estabelece uma nova referência de pesquisa, não uma substituição pronta para uso da infraestrutura de provas existente.
Há também uma limitação semântica compartilhada por todos os sistemas de prova. O Magnetar pode provar que um código especificado foi executado sobre entradas comprometidas. Ele não pode determinar se o código representava a política correta ou se uma fonte de entrada disse a verdade.
Considere um agente de IA que prova conformidade com uma regra de aprovação. A prova pode mostrar que a regra foi executada. Ela não pode mostrar que uma regra omitida deveria ter bloqueado a ação, nem que um feed de dados externo era preciso.
A mesma questão se aplica às finanças. Uma prova pode estabelecer que um programa de processamento de transações seguiu restrições codificadas sem revelar os detalhes das transações. Reguladores e contrapartes ainda precisam avaliar as regras, a proveniência das entradas, a governança e as condições excepcionais.
Essas limitações devem orientar a adoção. A computação baseada em provas é mais forte quando a declaração, o programa e os compromissos de entrada podem ser definidos com precisão. Ela é mais fraca quando organizações esperam que a criptografia resolva políticas ambíguas ou dados não confiáveis.
Três sinais mostrarão se o Magnetar avança além da pesquisa
O próximo teste é saber se desenvolvedores independentes conseguem reproduzir os ganhos do Magnetar e transformá-los em aplicações duradouras.
O primeiro sinal é evidência de implementação pública. Pesquisadores e desenvolvedores precisam de código, parâmetros, entradas de benchmark e instruções de build suficientes para reproduzir a faixa de 7,2 milhões a 8,7 milhões de ciclos por segundo.
A reprodução em outros processadores fortaleceria o argumento de desempenho da Microsoft. Resultados que variem acentuadamente entre configurações de hardware ou memória o restringiriam. As comparações também devem usar níveis de segurança e definições de carga de trabalho equivalentes.
Esse detalhe importa porque benchmarks de sistemas de prova são excepcionalmente sensíveis a escolhas de implementação. Uma configuração pode trocar tamanho de prova, memória, segurança ou pré-processamento por maior throughput. Rótulos comparáveis nem sempre significam garantias comparáveis.
O segundo sinal é uma aplicação real mantida por uma equipe externa ao grupo de pesquisa. Uma implantação confiável deveria usar código comum em Rust, Go ou C e gerar provas sob restrições operacionais realistas.
Um interpretador EVM é um possível teste. Um fluxo de trabalho regulamentado de processamento de dados ou um mecanismo de políticas para agentes seria igualmente informativo. O exemplo mais forte publicaria dados de latência, uso de memória, tamanho de prova e falhas operacionais.
Tal implantação testaria a alegação de que a computação de propósito geral baseada em provas com o Magnetar reduz o trabalho especializado de desenvolvimento. Compatibilidade de compilador, depuração e procedimentos de atualização importam tanto quanto o throughput de benchmark.
O terceiro sinal é a resposta de projetos zkVM concorrentes. Jolt, SP1, RISC Zero e outras equipes podem contestar os resultados da Microsoft por meio de novos benchmarks, provas menores, aceleração de hardware ou análises alternativas de segurança.
Uma resposta focada apenas no máximo de ciclos por segundo reforçaria o enquadramento da Magnetar. Uma resposta que demonstrasse menor custo total ou melhor confiabilidade em produção poderia enfraquecê-lo. O mercado precisa de comparações que cubram todo o pipeline de comprovação.
Os concorrentes também podem adotar componentes mais conservadores. Se a segurança com hashes padrão se tornar um requisito de compra, os projetos precisarão oferecer modos compatíveis ou explicar por que suas premissas representam uma alternativa aceitável.
O trabalho da Microsoft pode, portanto, influenciar o design de zkVMs mesmo sem se tornar a implementação dominante. Ele eleva o padrão esperado para explicar, em conjunto, as premissas de segurança, a compatibilidade de programação e os custos de recursão.
Os desenvolvedores devem acompanhar um lançamento utilizável, conjuntos independentes de benchmarks e aplicações que comprovem mais do que transações de criptomoedas. Esses eventos mostrariam se a arquitetura se generaliza além de cargas de trabalho de pesquisa cuidadosamente controladas.
Os compradores corporativos devem fazer outro conjunto de perguntas. Qual declaração exata a prova estabelece? Quais entradas permanecem privadas? Quais premissas protegem a prova e como o sistema responderá se essas premissas mudarem?
As equipes que avaliam a tecnologia também precisam de um registro duradouro das condições dos benchmarks e das decisões de segurança. Uma base de conhecimento de engenharia pesquisável pode conectar artigos, resultados de testes, notas de implementação e conclusões de revisões sem reduzir a decisão a um único número de destaque.
A computação de propósito geral baseada em provas com Magnetar já desafiou uma premissa conhecida: a segurança pós-quântica conservadora não exige necessariamente programas lentos e especializados. O próximo passo é verificar a própria Magnetar. Equipes independentes conseguem reproduzir os números, manter aplicações convencionais e preservar a segurança alegada sob a pressão da produção?
