Loading...
Este artigo é reproduzido de Proof Street, uma publicação independente sobre computação que preserva a privacidade: ZK, FHE, MPC, TEEs e identidade descentralizada. Publicado originalmente como "Confidentiality compared: what four privacy architectures promise" em 12 de agosto de 2026. Reproduzido com a permissão do autor como parte do Zcash Community Grant #339. Por Stephen Webber.
No final de julho, a Zama ativou um ambiente de conversão confidencial na mainnet do Ethereum, em beta privado antes de um lançamento público em setembro, que possibilita que um trader envie uma intenção criptografada que oculta o valor, a tolerância a slippage e a direção da operação.
Isso depende de uma pequena coreografia. O trader deposita duas transferências confidenciais, uma com os ativos reais e outra para a ponta oposta com valor zero, para que um observador veja um movimento bidirecional de tamanho oculto e não consiga distinguir uma compra de uma venda. Os market makers autorizados descriptografam a intenção, veem o tamanho, mas não a direção, e fazem cotações para ambos os lados. Um leilão de propostas seladas é liquidado on-chain, e apenas o market maker vencedor descobre a direção da operação. O resultado líquido é uma conversão executada em tamanho em uma chain pública, em que nenhuma parte isolada fora da operação jamais reúne o quadro completo.
A Zama descreve o produto como confidencial de ponta a ponta, mas o que essa confidencialidade realmente implica? A confidencialidade aqui exige confidencialidade ao longo de toda uma chain de ações, de modo que o público vê uma coisa, os licitantes perdedores veem mais, já que descriptografaram o tamanho da operação para cotá-la, e o licitante vencedor vê ainda mais. Em termos simples, cada etapa da sequência é assim por causa de uma decisão que alguém tomou sobre quem precisa saber o quê e quando. Seria bom resumir a confidencialidade como "ninguém vê nada", mas nada funcionaria na prática. A confidencialidade precisa ser estruturada e seguir uma sequência.
O interessante é que, quase dez anos antes desse lançamento, o Zcash introduziu a primeira camada de liquidação confidencial em uma blockchain pública, usando provas de conhecimento zero para ocultar o remetente, o destinatário e o valor de uma transação, ao mesmo tempo em que prova a todos que a transação era válida. Na década desde então, "confidencial" tornou-se o adjetivo para pelo menos quatro famílias distintas de tecnologia: transações blindadas, criptografia totalmente homomórfica, computação multipartidária e ambientes de execução confiáveis. Produtos das quatro famílias agora funcionam em produção, vários deles na mesma chain. Então, o que há dentro da embalagem?
As quatro famílias oferecem respostas diferentes e às vezes sobrepostas para quatro problemas diferentes e, como cada resposta agora chega embalada como um produto, a verdadeira tarefa é descobrir qual problema você realmente tem.
Qualquer alegação de confidencialidade, quando reduzida ao essencial, precisa responder a quatro perguntas. Quais dados estão ocultos? De quem? Durante qual fase da vida dos dados? E em que é preciso confiar para que a garantia sobreviva?
Como exemplo, considere o ambiente de conversão. Ele precisa ocultar o valor, a direção e o slippage. Por que não o par de ativos? A Zama diz que uma versão futura também o ocultará. De quem: do público e dos bots de front-running completamente, dos market makers que fazem cotações parcialmente, e do market maker vencedor menos que todos. Durante qual fase: durante a cotação e o leilão, com uma divulgação planejada na liquidação. E em quem você precisa confiar: a garantia repousa no próprio FHE, nos contratos inteligentes e em um sistema de gestão de chaves por limiar cujos operadores não devem entrar em conluio além de um limiar. Segundo o litepaper, nenhuma parte isolada pode jamais acessar as chaves de descriptografia.
É um projeto para executar tamanho sem divulgar a estratégia. Os market makers veem o tamanho porque não conseguem precificar uma cotação sem ele. O vencedor descobre a direção porque, bem, a liquidação exige isso.
O que o exemplo mostra é que uma alegação que soa binária, como se algo fosse ou não confidencial, na verdade se desdobra em um cronograma de exclusões. Há maneiras muito diferentes de chegar a alegações que soam iguais.
Uma transação blindada do Zcash oculta o remetente, o destinatário e o valor. O que permanece público é a prova: um argumento de conhecimento zero, verificável por qualquer pessoa que execute um nó, de que a transação oculta segue as regras. Os fundos blindados existem como notes criptografadas, cada uma um registro privado de um valor e de seu proprietário que aparece on-chain apenas como um compromisso criptográfico. Gastar uma note publica um nulificador, um valor que impede que a mesma note seja gasta duas vezes sem revelar qual era a note. Isso significa que a rede pode rejeitar gastos duplos sem jamais saber quais fundos foram movidos, portanto gastar não deixa um rastro ligando uma transação a outra. O papel da prova é estabelecer que quem gasta possuía a note, que os valores da transação se equilibram e que nenhum ZEC foi criado ou destruído, tudo isso sem divulgar nenhuma das quantidades envolvidas.
A propriedade distintiva do projeto se torna mais evidente quando se considera em que é preciso confiar. Não há um comitê que possa descriptografar uma transação blindada, nenhum conjunto de operadores cujo limiar de conluio importe, nenhum fornecedor de hardware cuja atestação precise ser acreditada. O que permanece na base de confiança é a matemática e a correção dos circuitos que codificam as regras. Para qualquer pessoa cujo modelo de ameaça inclua a própria infraestrutura, operadores que possam ser pressionados e fornecedores que possam ser comprometidos, essa lista curta é o produto.
De fato, essa base de confiança acabou de ser testada em produção. Em 29 de maio, Taylor Hornby, um pesquisador de segurança que auditava para a Shielded Labs, encontrou uma falha de solidez no circuito de prova do pool Orchard, presente desde o lançamento do pool em 2022, que, segundo a divulgação da Shielded Labs, poderia ter permitido a cunhagem ilimitada de ZEC falsificado dentro do Orchard sem qualquer rastro on-chain.
A correção de emergência foi lançada em cinco dias: o Orchard foi pausado em 2 de junho e restaurado em 3 de junho com um circuito corrigido. A publicação de remediação da ZODL descreveu o impacto de forma mais restrita que a Shielded Labs, caracterizando-o como um risco de gasto duplo dentro do pool, em vez de oferta falsificada, e informou que a privacidade dos usuários e o limite total de oferta não foram afetados.
A reconstrução da verificabilidade foi lançada mais tarde. Ironwood, ativado como NU6.3 em 28 de julho, sela permanentemente o pool Orchard, abre um novo pool no circuito corrigido, apoiado por auditorias independentes e trabalho de verificação formal, e encaminha todos os fundos de saída por uma catraca que limita os saques ao que entrou de forma verificável, restaurando a capacidade de cada usuário de verificar de forma independente a oferta circulante sem ver as transações de ninguém. O episódio é o registro da base de confiança em ação. Quando a correção do circuito falhou, a solução foi matemática e migração, não a discrição de um comitê, e o raio de impacto foi limitado pela auditabilidade que a arquitetura havia incorporado à fronteira do pool anos antes.
O que a blindagem obtém com essa base mínima de confiança é deliberadamente limitado. O estado oculto é um pagamento, valor passando de uma parte para outra. Não há estado compartilhado criptografado sobre o qual muitas partes computam, nem lógica de contratos confidenciais, nem um livro de ordens criptografado.
O FHE permite que a computação seja executada sobre ciphertext. No protocolo da Zama, a versão agora ativa no Ethereum, saldos e valores de transferência existem on-chain como identificadores criptografados segundo o rascunho do padrão ERC-7984, coprocessadores executam a aritmética criptografada off-chain e a descriptografia exige um quórum de operadores independentes de gestão de chaves, treze organizações no lançamento da mainnet, selecionadas por sua reputação e envolvimento operacional, para que nenhuma parte isolada consiga ler os dados. É isso que torna possível um livro de ordens criptografado ou um pool de lending confidencial: o estado oculto de muitas partes, compondo-se dentro de lógica compartilhada de contratos.
Mas e quanto ao comitê de gestão de chaves? Alguém precisa conseguir descriptografar, ou os dados não são utilizáveis. A resposta do projeto é fazer com que esse alguém seja um limiar de operadores independentes, em vez de um único custodiante, e controlar quem pode descriptografar quais valores por meio de controle de acesso inscrito nos próprios contratos, extensível a partes designadas, como auditores, um mecanismo de delegação cujas implicações de compliance pertencem ao próximo texto desta série. A questão para quem avalia soluções é se a composição, os incentivos e o limiar do comitê correspondem ao modelo de ameaça do avaliador.
A computação multipartidária divide os dados em partes distribuídas entre nós independentes, que juntos computam um resultado sem que nenhum nó reconstrua as entradas. Avishay Yanai, cofundador e CEO da Soda Labs, cuja máquina virtual de circuitos garbled executa lógica de contratos compatível com EVM sobre valores criptografados em produção na rede COTI, descreve um bom projeto de MPC em produção como aquele que garante que nenhuma parte isolada, seja um observador, um nó que executa a computação ou o fornecedor, jamais veja entradas em plaintext ou estado intermediário, e que todos vejam apenas o que a política de divulgação lhes concede. A garantia depende apenas da ausência de conluio, e essa é uma hipótese que você pode projetar e contratar, por exemplo, com operadores em jurisdições separadas, em clouds separadas e sob auditorias independentes, com exposição legal por conluio. O papel da criptografia aqui é o que ele chama de uma enorme redução de confiança, em vez de eliminação da confiança, para alcançar equivalência com a confiança que as instituições depositam nas câmaras de compensação. O conluio além do limiar quebra a privacidade, mas não a correção, já que, em projetos com auditabilidade pública, validadores externos ainda podem verificar que os resultados informados estão corretos sem participar da computação.
A ressalva é apenas que tal observador vê que uma transação aconteceu, quando, contra qual contrato, quem a enviou, além dos tamanhos dos lotes e das taxas. Um nó participante pode descobrir qual função foi executada e seus padrões de throughput. A correlação temporal é outra consideração, pois os níveis de atividade podem vazar mesmo quando os valores não vazam. E tudo o que o aplicativo produz em plaintext, divulgações pequenas e repetidas, pode se transformar em padrões potenciais para uma parte que esteja atenta a eles. "É o limite da promessa", esclarece ele, portanto os avaliadores devem exigir que os fornecedores o definam explicitamente. Nenhum modelo de computação corrige o envio de plaintext por, por exemplo, um cliente comprometido. O protocolo computa fielmente sobre o que recebe. Quem fala com quem é um problema de transporte, e compliance é uma política, não um mecanismo: "Nenhuma criptografia toma essa decisão por você."
Projetos com circuitos garbled funcionam em rodadas constantes, com o material criptográfico pesado pré-computado antes de existirem entradas, o que torna viáveis cargas de trabalho em ritmo de transações, enquanto os protocolos de secret-sharing pagam viagens de ida e volta pela rede por operação. E, segundo Yanai, enquanto algumas famílias de MPC protegem os valores, mas não o fato da computação, projetos com circuitos garbled podem estender a cobertura a endereços de contrapartes e tipos de ativos. A propriedade mais importante dessa família para esta comparação, porém, é que o MPC é uma arquitetura por si só e também um ingrediente dentro das outras famílias: o comitê de chaves por limiar sob uma implementação de FHE é, ele próprio, uma computação multipartidária. A pergunta do avaliador, no enquadramento de Yanai, é "o que meu comitê faz e o que pago além disso?" Se o comitê existe de qualquer forma, executar a própria computação em MPC pode remover uma camada externa dispendiosa.
Vale esclarecer que dois produtos muito diferentes são discutidos usando a mesma sigla. O MPC de custódia divide uma chave de assinatura entre várias partes para que nenhuma delas consiga assinar sozinha; ele protege um segredo, e a computação conjunta envolvida é uma única operação fixa, que produz uma assinatura. O MPC de computação executa lógica geral de programas sobre dados que permanecem ocultos durante todo o processo e envolve entradas de muitas partes, lógica arbitrária de contratos e operação contínua. A matemática é o que os dois têm em comum. Operacionalmente, porém, um é usado para gestão de chaves e o outro é um ambiente de execução confidencial.
Um TEE é uma região de um processador isolada por hardware que mantém os dados criptografados na memória e blindados do sistema operacional, do hypervisor e do operador da máquina, com a atestação remota permitindo que uma parte externa verifique qual código está sendo executado dentro dela. O projeto obtém as duas coisas pelas quais as famílias criptográficas pagam caro, generalidade e velocidade: um enclave executa programas comuns a um custo próximo do normal, razão pela qual os TEEs sustentam a maioria das ofertas de computação confidencial das grandes clouds e um conjunto crescente de infraestrutura de chain.
A base de confiança é a troca, porque a garantia é tão forte quanto o projeto e a cadeia de suprimentos do fornecedor de hardware, a infraestrutura de atestação e a resistência do enclave à extração por side-channel, uma classe de ataque com uma longa história publicada. Os projetistas de TEE conhecem esse registro melhor que seus críticos. Escolher a arquitetura significa fazer uma aposta ponderada de que a confiança no hardware mais a atestação é o preço certo para executar cargas de trabalho reais em velocidade real, e, para muitas implementações, é.
O Zcash blindado poderia atender ao caso de uso de um ambiente de negociação confidencial? Não, mas isso não é uma deficiência. Um ambiente de RFQ é um estado compartilhado criptografado sob lógica de contratos, com intenções ocultas de muitas partes se compondo dentro de um leilão que também funciona às cegas. Isso é mais aplicável a algo como MPC, com estado privado compartilhado sob interação frequente, um livro de ordens, um ciclo de netting. A blindagem não tem substrato para isso; seu estado oculto é um pagamento entre duas partes. O próprio ambiente é adequado para FHE ou MPC, e vale notar que, quando a Zama o construiu, a confidencialidade que ele oferece é um cronograma de divulgações para market makers identificados e autorizados, o que é necessário para a negociação institucional. Mas esse é um produto diferente daquele que uma transação blindada oferece: confidencialidade sem whitelist e sem qualquer parte que eventualmente descubra sua direção.
E quanto a pagamentos corporativos e folha de pagamento? Esse é um mercado que todos os fornecedores de FHE e MPC agora disputam, e é exatamente o problema para o qual a blindagem foi criada: valores ocultos, contrapartes ocultas, validade pública. Em princípio, uma chain blindada é a resposta disponível com a base de confiança mais forte: sem comitê, sem fornecedor, sem conjunto de operadores. Na prática, o mercado de pagamentos corporativos está sendo conquistado pela infraestrutura, pela integração com ERC-20, pelos custodiantes existentes, pelas ferramentas de compliance existentes e pelas denominações em stablecoins, e o Zcash blindado oferece um ativo diferente em uma chain diferente. Mas ele se encaixa bem na forma do problema e está simplesmente aguardando integração. A criptografia consegue fazer isso, portanto as preocupações práticas têm a ver com aquilo ao que a stack ao redor se conecta.
Também vale observar o que as outras três famílias oferecem, e a blindagem não: uma parte que pode ser coagida. Um comitê por limiar pode receber uma ordem judicial, um fornecedor de enclaves pode ser intimado por suas chaves de assinatura, e um conjunto de operadores tem uma jurisdição. Uma instituição que precisa de um caminho de compliance pode considerar o comitê como o produto. Também é, visto de outra perspectiva, a vulnerabilidade.
Se olharmos novamente para os casos analisados acima, veremos um quadro com sobreposições. A maioria das implementações de FHE tem MPC por limiar por baixo como camada de descriptografia. Provas de conhecimento zero certificam entradas criptografadas antes de o FHE consumi-las e, em sistemas de circuitos garbled, podem certificá-las posteriormente, dando aos usuários uma saída forçada que não depende da disponibilidade da rede, uma prática emprestada das arquiteturas de rollup. Os TEEs aparecem dentro de nós de MPC como defesa em profundidade, os nós de gestão de chaves da Zama executam sua parte da computação dentro de enclaves de hardware, e os TEEs hospedam cada vez mais os provadores e builders de sistemas cujas garantias finais são criptográficas. Uma comparação escrita daqui a cinco anos poderá achar difícil localizar as costuras. Mas a composição ocorre em apenas uma direção.
É por isso que a forma duradoura da pergunta do avaliador não é sobre "qual tecnologia". O que importa procurar é como a confidencialidade é sequenciada, o que é excluído e o que impõe a exclusão, seja a matemática e a correção dos circuitos, a ausência de conluio de um comitê, um limiar de nós honestos ou o silício de um fornecedor. Leia qualquer alegação de confidencialidade perguntando o que está oculto, de quem, até quando e com base na palavra de quem, e então você saberá.
Divulgação: este texto foi apoiado por um Zcash Community Grant. A ZCG não revisou nem aprovou este texto antes da publicação. Os compromissos de financiamento da Proof Street estão listados na página de financiamento.
Páginas relacionadas: Shielded Pools (Using_Zcash) · Viewing Keys · a página "quem pode ver o quê" em Start_Here — substitua pelos caminhos exatos da wiki