Fundamentação Teórica

Este capítulo apresenta o conjunto de conceitos necessários para acompanhar o restante do trabalho. A premissa adotada é que o leitor não precisa de conhecimento prévio do domínio. Cada bloco temático é introduzido a partir do nível mais elementar e desenvolvido até o ponto em que se conecta diretamente com a solução proposta na §4.2. A ordem dos tópicos vai do mais externo (a infraestrutura de blockchain pública) para o mais interno (a teoria do mecanismo de leilão), passando pelos pilares criptográficos que tornam possível a interseção entre os dois.

2.1 Blockchain e contratos inteligentes

Esta seção constrói os conceitos de base: o que é uma blockchain (§2.1.1), o Bitcoin como ponto de partida (§2.1.2), o salto de programabilidade da Ethereum (§2.1.3), o modelo de execução e custo da EVM (§2.1.4) e, por fim, a observabilidade pública do mempool (§2.1.5), propriedade que conecta esta fundamentação ao problema central do trabalho.

2.1.1 O que é uma blockchain

Uma blockchain é um livro-razão público (registro oficial e cronológico de transações), distribuído e replicado em rede. Sua estrutura de dados central é uma cadeia de blocos, cada um contendo um conjunto de transações. Cada bloco carrega o resultado de uma função de hash criptográfico (transformação determinística que produz um valor curto e único a partir de qualquer entrada) aplicada ao bloco anterior, formando um encadeamento que torna inviável alterar registros antigos sem invalidar todos os blocos posteriores (NAKAMOTO, 2008). A combinação dessa estrutura com um protocolo de consenso, que define qual é o próximo bloco válido, permite que múltiplos participantes mantenham uma cópia idêntica do livro-razão sem precisarem confiar uns nos outros nem em uma autoridade central.

Por uma analogia controlada, pode-se pensar na blockchain como um caderno de anotações mantido em sincronia por vários auditores espalhados pelo mundo. Cada nova página é proposta por um auditor e validada coletivamente; uma vez aceita, ela é selada e distribuída. Tentativas posteriores de adulterar páginas antigas falham porque cada selo depende de todos os selos anteriores. A diferença em relação a registros tradicionais é que ninguém precisa ser dono do caderno: o caderno é a soma das cópias mantidas pelos auditores.

2.1.2 Bitcoin como ponto de partida

A primeira realização prática dessa arquitetura foi o Bitcoin, descrito por Nakamoto (2008) em um whitepaper¹ curto e influente. O Bitcoin definiu um protocolo de moeda digital descentralizada operando sobre uma blockchain pública, com transações assinadas por chaves criptográficas e validadas por um mecanismo de consenso por prova de trabalho, ou Proof of Work, em que participantes competem para resolver um problema computacionalmente caro, e o primeiro a encontrar a solução ganha o direito de propor o próximo bloco e receber uma recompensa. O script embutido nas transações do Bitcoin é deliberadamente limitado: permite verificações de assinatura e algumas operações condicionais, mas não é Turing-completo, isto é, não suporta laços nem cálculos arbitrários.

Essa simplicidade foi uma escolha de projeto, pensada para minimizar a superfície de ataque e garantir terminação. O custo, contudo, foi a impossibilidade de programar comportamentos sofisticados sobre o Bitcoin sem recorrer a camadas externas. Esse foi o gatilho para a próxima geração de blockchains.

2.1.3 A Ethereum e o salto para programabilidade

A Ethereum, proposta por Buterin (2014) no whitepaper fundacional e formalizada por Wood (2014) no Yellow Paper², generalizou a ideia da blockchain ao introduzir um modelo de execução Turing-completo. Cada nó da rede executa uma máquina virtual abstrata, a Ethereum Virtual Machine (EVM), capaz de processar bytecode arbitrário³. Os programas armazenados na blockchain são chamados de contratos inteligentes (smart contracts), e podem implementar qualquer lógica computável dentro dos limites de recursos disponíveis.

A consequência prática é profunda. Em vez de a blockchain executar apenas transferências de saldo, ela passa a executar programas: leilões, mercados de tokens, sistemas de governança, oráculos de preço, esquemas de empréstimo, cofres descentralizados. O custo dessa expressividade é que cada operação executada precisa ser paga em uma unidade interna chamada gás, ajustada para refletir o custo computacional, de armazenamento e de comunicação imposto à rede.

Os contratos inteligentes na Ethereum são tipicamente escritos em Solidity, linguagem de alto nível que se compila para o bytecode da EVM. O ciclo de vida é simples: um contrato é implantado por meio de uma transação especial, recebe um endereço único e passa a expor funções públicas que outros contratos ou usuários podem invocar. O estado do contrato (suas variáveis em memória persistente) é mantido na blockchain e atualizado por cada chamada bem-sucedida.

2.1.4 EVM, gás e transações

A EVM é uma máquina de pilha (stack machine) com instruções aritméticas, lógicas, de controle de fluxo, de leitura e escrita de armazenamento, e de comunicação entre contratos (WOOD, 2014). Cada instrução tem um custo de gás associado. Quando um usuário envia uma transação, ele declara um limite máximo de gás disposto a gastar e um preço unitário em moeda da rede. A transação é executada até atingir o limite ou terminar normalmente; se atingir o limite, o estado é revertido, mas o gás consumido até ali é cobrado.

Esse modelo serve a três propósitos. Primeiro, evita laços infinitos e ataques de negação de serviço, já que toda execução tem custo finito. Segundo, cria um leilão implícito de prioridade: transações que pagam mais por unidade de gás tendem a ser incluídas mais rapidamente. Terceiro, fornece uma medida objetiva e comparável de custo computacional, propriedade que será explorada extensivamente na avaliação do capítulo 5.

Cada transação atravessa três etapas: ela é criada e assinada pela carteira do usuário, é difundida pela rede peer-to-peer⁴ e fica visível em uma área de espera chamada mempool, e finalmente é incluída em um bloco por um produtor de blocos (validador⁵, no caso da Ethereum atual, que opera por Proof of Stake desde 2022). Essas três etapas são públicas e observáveis por qualquer nó da rede.

2.1.5 Mempool e a observabilidade pública

O mempool é o ponto crítico para o problema central deste TCC. Embora seja um detalhe de implementação, e não uma estrutura fixada formalmente no protocolo, ele é, na prática, o espaço onde transações pendentes ficam expostas até serem confirmadas. Qualquer nó pode ler o mempool. Bots, validadores e observadores adversariais o leem o tempo todo (DAIAN et al., 2020).

Essa observabilidade não decorre de uma falha de implementação, mas do fato de que, para uma transação ser incluída em um bloco, ela precisa ter sido difundida na rede antes. A transparência é a contrapartida da descentralização: para que múltiplos nós cheguem a um acordo sobre qual é o próximo bloco, todos precisam conhecer as transações candidatas. Qualquer mecanismo de privacidade aplicado sobre uma blockchain pública precisa lidar com essa propriedade. Em particular, qualquer mecanismo que pretenda ocultar lances de leilão precisa garantir que o conteúdo do lance, e não apenas a sua existência, permaneça inacessível durante toda a janela de exposição.

A literatura propõe paliativos para essa exposição. Mempools privados como o Flashbots Protect⁶ ocultam a transação individual do mempool, mas exigem confiança no operador do serviço e fragmentam a rede.

Esquemas de threshold encryption (em que a decifração só ocorre quando uma fração mínima de detentores de fragmentos da chave coopera) no nível do consenso prometem cifrar transações até a inclusão em bloco, mas envolvem premissas de honestidade entre validadores (por exemplo, que uma fração majoritária não coopere para censurar ou reordenar transações) ainda não realizadas em produção. Soluções de ordenação determinística por timestamp eliminam parte da reordenação, mas não atacam frontrunning baseado em observação. Em todas essas abordagens, o que se observa é um padrão recorrente: as mitigações reduzem a margem de ataque em uma dimensão e a deslocam para outra.

2.2 Criptografia: dos fundamentos à FHE

Esta seção percorre a trilha criptográfica que culmina na FHE: os fundamentos simétricos e assimétricos (§2.2.1), as funções hash (§2.2.2), o conceito de homomorfismo (§2.2.3), as construções parcialmente homomórficas (§2.2.4), o avanço de Gentry (§2.2.5) e a evolução dos esquemas até o TFHE (§2.2.6).

2.2.1 Criptografia simétrica e assimétrica

A criptografia moderna, em seu sentido mais amplo, estuda como transformar mensagens de modo a torná-las inteligíveis apenas a destinatários autorizados. Dois grandes paradigmas dominam a literatura.

A criptografia simétrica usa uma única chave compartilhada entre emissor e receptor. A mesma chave que cifra é a que decifra. Esse paradigma é eficiente computacionalmente e é a base de cifradores como o Advanced Encryption Standard (AES). O ônus, contudo, é o problema da distribuição de chaves: para que duas partes comuniquem-se com segurança, elas precisam, antes, ter trocado uma chave secreta por algum canal seguro.

A criptografia assimétrica, ou de chave pública, resolve esse problema. Cada participante possui um par de chaves matematicamente relacionadas: uma pública, divulgável a qualquer um, e uma privada, mantida em segredo. O que é cifrado com uma só pode ser decifrado com a outra. A construção foi proposta de forma seminal por Diffie e Hellman (1976), em artigo intitulado New directions in cryptography. Pouco depois, Rivest, Shamir e Adleman (1978) publicaram o RSA, primeiro esquema concreto e largamente adotado de criptografia de chave pública. A ideia central permite duas operações fundamentais. Primeiro, qualquer um pode cifrar uma mensagem para o detentor da chave privada, garantindo confidencialidade na comunicação. Segundo, o detentor da chave privada pode produzir uma assinatura sobre a mensagem que qualquer outro participante pode verificar, garantindo autenticidade e integridade.

Em blockchains públicas, a criptografia assimétrica é o que permite que cada usuário tenha uma identidade (representada pela chave pública, ou por um endereço derivado dela) e assine transações sem revelar a chave privada.

2.2.2 Funções hash criptográficas

Funções hash criptográficas são funções determinísticas que recebem uma entrada de tamanho arbitrário e produzem uma saída de tamanho fixo. Funções como SHA-256, usada no Bitcoin (NAKAMOTO, 2008), e Keccak-256, usada na Ethereum (WOOD, 2014), são projetadas para satisfazer três propriedades-chave: são de mão única, pois, dado um hash, é computacionalmente inviável recuperar a entrada original; são resistentes a colisões, já que é inviável encontrar duas entradas distintas que produzam o mesmo hash; e são determinísticas, pois a mesma entrada sempre gera a mesma saída.

Funções hash são onipresentes em sistemas criptográficos. Elas formam a coluna vertebral do encadeamento de blocos descrito na seção anterior, sustentam estruturas como árvores de Merkle, integram esquemas de assinatura digital, e são o ingrediente central do esquema commit-reveal discutido em §1.2.3.

2.2.3 O conceito de homomorfismo em criptografia

Em álgebra, uma função $f$ é dita homomórfica em relação a uma operação $\circ$ quando $f(a \circ b) = f(a) \circ f(b)$. Trazido para a criptografia, o conceito gera uma propriedade peculiar: existem esquemas em que operações sobre o texto cifrado correspondem a operações sobre o texto claro. Aplicar uma soma sobre dois ciphertexts (textos cifrados, isto é, mensagens já transformadas pela cifragem), por exemplo, e em seguida decifrar, produz o mesmo resultado de somar os textos claros e decifrar.

Essa propriedade permite delegar computação sobre dados confidenciais a partes não confiáveis: a parte não confiável manipula ciphertexts e devolve um ciphertext de resultado, sem nunca ter acesso aos textos claros envolvidos. O destinatário, com a chave privada, decifra apenas o resultado final (GENTRY, 2009).

2.2.4 Construções parciais: aditivas e multiplicativas

Esquemas com propriedades homomórficas existem desde a década de 1970, mas suportavam apenas uma das operações algébricas básicas, não as duas simultaneamente.

O RSA, proposto por Rivest, Shamir e Adleman (1978), é multiplicativamente homomórfico: o produto de dois ciphertexts decifra-se como o produto dos textos claros. Esquemas como ElGamal compartilham essa propriedade. Outros esquemas, como o de Paillier (1999), são aditivamente homomórficos: a soma (em um corpo apropriado) de dois ciphertexts decifra-se como a soma dos textos claros. Essas construções são chamadas de homomórficas parciais, ou Partially Homomorphic Encryption (PHE).

Embora úteis em aplicações específicas, como votação eletrônica e estatística sobre dados cifrados, as construções parciais são limitadas. Computações arbitrárias requerem combinar somas e multiplicações, e nenhum esquema clássico oferecia essa combinação. Por mais de três décadas, a existência de uma construção que permitisse computar funções arbitrárias sobre dados cifrados foi um problema em aberto.

2.2.5 Gentry e a primeira FHE viável

Gentry (2009), em sua tese de doutorado em Stanford, apresentou o primeiro esquema de Fully Homomorphic Encryption (FHE) de fato viável. A construção parte de um esquema homomórfico parcial baseado em reticulados (lattices) e introduz uma técnica chamada bootstrapping: a cada operação, o ciphertext acumula um ruído que cresce com a complexidade da computação; quando o ruído se aproxima de um limite, o bootstrapping aplica uma decifração homomórfica que reduz o ruído sem precisar acessar a chave privada. O resultado é um esquema capaz de computar funções de profundidade arbitrária.

A construção original era extremamente custosa em termos computacionais e impraticável para qualquer aplicação real. Sua importância, contudo, foi conceitual: provou que FHE existe e abriu o caminho para uma sucessão rápida de melhorias.

2.2.6 Evolução: BGV, BFV, CKKS e TFHE

Após o trabalho de Gentry, a comunidade desenvolveu várias famílias de esquemas FHE, cada uma otimizada para tipos específicos de carga de trabalho.

O esquema BGV, proposto por Brakerski, Gentry e Vaikuntanathan em 2014, foi um marco de eficiência na computação homomórfica sobre inteiros exatos. Reduziu drasticamente o custo de cada operação por meio de técnicas de comutação de módulos (modulus switching) que evitam a necessidade de bootstrapping para circuitos de profundidade limitada conhecida em tempo de compilação. O BFV, cujo acrônimo combina os autores Brakerski, Fan e Vercauteren, foi construído em duas etapas. Brakerski (2012) propôs um esquema scale-invariant baseado no problema Learning With Errors (LWE, formalizado na §2.4.2), alternativo ao BGV por dispensar a comutação de módulos e por manter o crescimento do ruído linear no número de multiplicações homomórficas. Em seguida, Fan e Vercauteren (2012) portaram essa construção para o anel polinomial (RLWE), tornando-a computacionalmente eficiente. Voltado também a inteiros exatos, o BFV é amplamente utilizado em bibliotecas como SEAL (Microsoft) e PALISADE.

O esquema CKKS, proposto por Cheon, Kim, Kim e Song em 2017, especializou-se em aritmética aproximada sobre números reais ou complexos. Em vez de cifrar inteiros exatos, ele cifra reais com uma precisão controlada, tornando-se a escolha natural para aplicações em aprendizado de máquina e estatística sobre dados cifrados.

Por fim, o esquema TFHE, proposto inicialmente por Chillotti, Gama, Georgieva e Izabachène em 2016 e estendido em Chillotti et al. (2020a), opera no toro (torus), estrutura matemática que permite construir um bootstrapping extremamente rápido, da ordem de poucas dezenas de milissegundos. Em vez de operar sobre vetores grandes de inteiros como BGV/BFV, o TFHE é otimizado para circuitos booleanos e para operações de baixa profundidade aritmética intercaladas com avaliações de funções não lineares. Essa característica é exatamente o que torna o TFHE adequado a aplicações de smart contracts, onde operações de comparação, seleção condicional e manipulação de bits são frequentes.

A biblioteca CONCRETE, publicada por Chillotti et al. (2020b) no workshop WAHC, é a implementação de referência do TFHE mantida pela Zama, e é a base sobre a qual plataformas FHE on-chain como a fhEVM da própria Zama e a Fhenix CoFHE são construídas.

2.3 TFHE e a plataforma Fhenix CoFHE

Esta seção aproxima a teoria da plataforma adotada: o funcionamento do TFHE em alto nível (§2.3.1), os tipos cifrados expostos pela Fhenix (§2.3.2), as operações homomórficas relevantes para o contrato (§2.3.3), a arquitetura do coprocessador CoFHE com a Threshold Services Network (§2.3.4) e o fluxo de decifração via TSN (§2.3.5) que a implementação deste trabalho emprega.

2.3.1 TFHE em alto nível

Sem entrar nos detalhes do maquinário matemático, o TFHE pode ser entendido a partir de três decisões de projeto. Primeiro, ele cifra valores com base em um problema computacional difícil chamado Learning With Errors sobre o toro, introduzido em sua versão clássica por Regev (2005). O ciphertext é um vetor de números que carrega o texto claro disfarçado por ruído aleatório controlado. Segundo, as operações homomórficas são definidas como manipulações sobre esses vetores que preservam a relação ruído-texto, com ruído crescendo a cada passo. Terceiro, o bootstrapping atua como uma operação de redução de ruído que pode, simultaneamente, avaliar uma função arbitrária sobre o texto claro disfarçado, transformando uma operação de manutenção em uma operação útil.

A consequência prática é que o TFHE permite construir circuitos arbitrários sobre ciphertexts, com o custo dominante concentrado em cada chamada de bootstrapping. Operações simples (somas, multiplicações por constantes) são baratas; operações que envolvem comparações ou seleções condicionais (como gt, eq e select) costumam disparar bootstrapping e são, portanto, ordens de grandeza mais caras. Essa diferença será central na análise de gás do capítulo 5.

2.3.2 Tipos cifrados na Fhenix

A Fhenix (2026a) é uma plataforma de FHE para blockchains compatíveis com a EVM. Seu núcleo é um coprocessador chamado CoFHE (Confidential FHE coprocessor) que se acopla a chains existentes como Ethereum, Arbitrum e Base, sem exigir uma rede dedicada. A arquitetura de coprocessador é, em linhas gerais, a mesma adotada pela fhEVM da Zama em sua versão atual (HINDI, 2024); a diferença substantiva entre as duas plataformas está no modelo de decifração, detalhado em §2.3.4. A plataforma disponibiliza uma biblioteca Solidity, @fhenixprotocol/cofhe-contracts/FHE.sol, que oferece os seguintes tipos cifrados nativos:

• euint8, euint16, euint32, euint64 e euint128: inteiros sem sinal cifrados, com o número de bits indicado;
• ebool: valores booleanos cifrados;
• eaddress: endereços de carteira cifrados.

Para receber um valor cifrado pelo cliente, a Fhenix usa estruturas chamadas InEuint* (por exemplo, InEuint64). O cliente cifra o valor no navegador usando o pacote @cofhe/sdk, baseado em TFHE em WebAssembly (WASM), e a biblioteca produz uma struct contendo o handle (referência curta para um ciphertext, semelhante a um ponteiro) e a assinatura do verificador do CoFHE. O contrato converte essa struct em um euint64 interno chamando FHE.asEuint64(encInput), sem precisar lidar diretamente com o ciphertext bruto.

Os ciphertexts são objetos grandes (na ordem de dezenas de quilobytes para tipos de 64 bits), e armazená-los integralmente em storage (memória persistente da blockchain, em que os dados de um contrato permanecem entre chamadas e cujo uso é pago em gás) seria proibitivamente caro. A Fhenix contorna isso por meio de execução simbólica (symbolic execution): o storage na blockchain mantém apenas handles, identificadores determinísticos derivados da operação e de seus operandos, enquanto os ciphertexts efetivos e a computação FHE são delegados ao coprocessador off-chain (executado fora da blockchain principal), conforme detalhado a seguir (FHENIX, 2026b).

2.3.3 Operações homomórficas relevantes

A biblioteca FHE.sol da Fhenix expõe um conjunto de operações homomórficas em Solidity análogo ao oferecido por outras plataformas FHE on-chain. Para os fins deste trabalho, as operações mais relevantes são as seguintes.

A operação FHE.add(a, b) recebe dois ciphertexts inteiros e retorna o ciphertext da soma. As variantes FHE.sub e FHE.mul cobrem subtração e multiplicação, com custo crescente. A operação FHE.gt(a, b) retorna um ebool cifrado indicando se o primeiro operando é maior que o segundo, sem revelar nenhum dos dois. As variantes FHE.lt, FHE.eq, FHE.ne, FHE.gte e FHE.lte cobrem as demais comparações. A operação FHE.select(c, a, b) recebe um ebool cifrado c e dois ciphertexts a e b, retornando a se c é verdadeiro e b caso contrário, sem revelar qual ramo foi escolhido. Essa operação é o equivalente cifrado de um operador ternário e é peça-chave da técnica de máscara homomórfica utilizada na solução proposta na §4.2.

Há ainda operações lógicas booleanas que combinam ciphertexts ebool: FHE.and, FHE.or e FHE.not. Combinadas com FHE.eq e FHE.select, elas permitem expressar o padrão de first-match determinístico usado para tratar empates entre lances iguais, detalhado na §4.2. A operação FHE.max(a, b) retorna o maior entre dois ciphertexts inteiros sem revelar qual deles é, e é usada para encontrar o lance vencedor por torneio homomórfico.

Para o controle de acesso a handles, a biblioteca expõe três primitivas. FHE.allowThis(handle) autoriza o próprio contrato a operar sobre um ciphertext em chamadas futuras, sem o que o handle não é reutilizável. FHE.allow(handle, address) autoriza um endereço específico a decifrar o ciphertext, útil, por exemplo, para que o vencedor de um leilão recupere o próprio lance. FHE.allowPublic(handle) marca o ciphertext como publicamente decifrável, permitindo que qualquer participante peça a decifração à rede de threshold descrita na subseção 2.3.5.

2.3.4 Arquitetura: CoFHE e a Threshold Services Network

A arquitetura da Fhenix é composta por três camadas (FHENIX, 2026b). Os contratos Solidity são executados normalmente em uma chain EVM convencional, como Ethereum, Arbitrum ou Base, isto é, on-chain (executado e registrado dentro da blockchain principal, com todos os custos e garantias dela). O CoFHE é uma rede off-chain de coprocessadores que armazena os ciphertexts efetivos e executa, em pipeline, as operações homomórficas requisitadas pelos contratos. A Threshold Services Network (TSN) é uma terceira camada, dedicada exclusivamente à decifração: ela detém a chave de decifração distribuída entre múltiplos participantes via secret sharing (técnica criptográfica em que um segredo é dividido em fragmentos de modo que apenas a combinação de um número mínimo de fragmentos permite reconstruí-lo), e nenhuma decifração ocorre sem que pelo menos t dentre N participantes cooperem; esse número mínimo de participantes é o que se denomina quórum.

O fluxo típico de uma operação cifrada é o seguinte. O contrato Solidity recebe um handle como entrada (proveniente de uma chamada anterior ou de uma struct InEuint* recém-convertida). Quando o contrato chama uma operação como FHE.gt(handleA, handleB), a EVM, na verdade, executa um comando que registra a operação e produz um novo handle para o resultado. O cálculo efetivo, sobre os ciphertexts grandes, é executado pelo CoFHE, que mantém a correspondência entre handles e ciphertexts. O contrato pode encadear quantas operações desejar, manipulando handles, sem que nenhum ciphertext jamais entre na storage da blockchain.

Tanto a Fhenix quanto a fhEVM da Zama (ZAMA, 2024; HINDI, 2024) operam, em sua versão atual, com decifração distribuída por Multi-Party Computation por limiar⁷. A diferença substantiva entre as duas plataformas está na orquestração do fluxo de revelação, detalhada na §2.3.5: a Zama opera por callback de oráculo dentro do contrato (chamada automática que um serviço externo dispara de volta no contrato quando há um valor pronto para ser entregue), enquanto a Fhenix expõe a TSN como serviço consultado pelo cliente, sem callback. Esse contraste afeta como o ciclo de vida do contrato precisa ser modelado e é retomado em §4.1.

O modelo é eficiente em armazenamento on-chain, mas introduz acoplamento entre três sistemas (a blockchain, o CoFHE e a TSN). Esse acoplamento é uma das fontes de discussão de robustez no capítulo 5.

2.3.5 Decifração via TSN

A última peça da arquitetura é a decifração. Em algum momento, o contrato precisa expor um valor em texto claro a um usuário ou a outro contrato. Por exemplo, ao final do leilão, o preço de fechamento e a identidade do vencedor precisam ser publicados para que o pagamento seja efetuado. Na Fhenix, isso é feito por meio de um fluxo cliente-orquestrado, em vez do callback de oráculo dentro do contrato adotado pela fhEVM da Zama.

O contrato, ao decidir que um determinado ciphertext deve se tornar acessível, chama FHE.allowPublic(handle). Esse handle passa a ser publicamente decifrável, mas a decifração propriamente dita ocorre fora do contrato. Um cliente off-chain (o frontend do usuário, um bot designado ou qualquer participante interessado) consulta a TSN via SDK e recebe o valor em texto claro acompanhado de uma assinatura coletiva da rede de threshold. Esse valor é então publicado de volta on-chain em uma transação subsequente, por exemplo finalizeSettlement(clearPrice, clearWinner), e o contrato verifica, com FHE.verifyDecryptResult, que os valores em texto claro correspondem de fato aos handles cifrados marcados anteriormente.

A latência total dessa operação é dominada pelo round-trip (ida e volta da requisição) com a TSN e pela transação de publicação subsequente, e não pelo tempo de bloco em si. A diferença em relação à fhEVM da Zama está em quem orquestra a decifração. Na Zama, o oráculo dispara um callback dentro do contrato, deixando-o passivo aguardando a chamada do oráculo. Na Fhenix, é um participante externo que decifra via TSN e publica o resultado, deixando o contrato passivo aguardando essa publicação. Em ambos os casos a decifração é assíncrona e impõe ao desenvolvedor o cuidado de modelar o ciclo de vida do contrato como uma máquina de estados explícita (por exemplo, distinguindo a fase de lances, a de solicitação de revelação e a de liquidação), com previsão de timeout caso nenhum participante publique o resultado em tempo hábil.

2.4 Resistência a ataques quânticos

Esta seção justifica uma propriedade colateral relevante da escolha criptográfica. Apresenta a ameaça quântica à criptografia clássica (§2.4.1), a família de problemas em reticulados sobre a qual o TFHE se apoia (§2.4.2), o argumento que o torna considerado quantum-resistant (§2.4.3) e a razão prática de isso importar em registros públicos imutáveis (§2.4.4).

2.4.1 Computação quântica e cripto clássica

A computação quântica é um modelo computacional que utiliza propriedades da mecânica quântica (superposição, emaranhamento, interferência) para realizar certas tarefas com custo computacional significativamente menor que computadores clássicos quando o tamanho do problema cresce. Embora ainda não existam computadores quânticos suficientemente grandes para representar uma ameaça concreta, dois algoritmos quânticos publicados nos anos 1990 mostraram que a chegada eventual desses computadores compromete partes substanciais da criptografia clássica.

O primeiro é o algoritmo de Shor (SHOR, 1994), que resolve o problema de fatoração de inteiros e o problema do logaritmo discreto em tempo polinomial em um computador quântico. Como a segurança do RSA depende da dificuldade da fatoração, e a segurança de esquemas baseados em curvas elípticas (incluindo as assinaturas usadas em Bitcoin e Ethereum) depende do logaritmo discreto, ambos os esquemas tornam-se inseguros na presença de um computador quântico de escala suficiente.

O segundo é o algoritmo de Grover (GROVER, 1996), que acelera quadraticamente a busca em espaços não estruturados. Para criptografia simétrica e funções hash, o efeito é menos catastrófico: dobrar o tamanho da chave (por exemplo, passar de AES-128 para AES-256) restaura o mesmo nível de segurança. Para criptografia assimétrica, contudo, não existe contramedida análoga, e o problema precisa ser atacado pela substituição completa do esquema.

2.4.2 Lattice-based cryptography e LWE

A resposta da comunidade criptográfica à ameaça quântica foi a busca por problemas computacionais que permaneçam difíceis mesmo para computadores quânticos. Esse campo ficou conhecido como criptografia pós-quântica (Post-Quantum Cryptography, ou PQC). O Instituto Nacional de Padrões e Tecnologia dos Estados Unidos (NIST) conduziu, ao longo da década de 2010, um processo de padronização de esquemas PQC, que culminou na finalização de várias famílias de algoritmos como padrões oficiais.

Entre as famílias mais promissoras está a criptografia baseada em reticulados (lattice-based cryptography). Reticulados são estruturas matemáticas formadas por combinações inteiras de vetores em um espaço euclidiano, e admitem problemas computacionais (encontrar o vetor mais curto, encontrar o vetor mais próximo) cuja dificuldade resiste, até onde se sabe, a algoritmos quânticos eficientes.

O problema computacional concreto que sustenta a maior parte das construções PQC modernas é o Learning With Errors (LWE), introduzido por Regev (2005). Em essência, dado um conjunto de equações lineares perturbadas por ruído, é difícil recuperar a solução exata. A dificuldade do LWE pode ser reduzida à dificuldade de problemas em reticulados, oferecendo garantias de segurança bem fundamentadas.

2.4.3 Por que TFHE é considerado quantum-resistant

A relevância de LWE neste TCC é que o TFHE, esquema utilizado pela Fhenix CoFHE, é construído precisamente sobre uma variante do problema, o LWE sobre o toro (Torus LWE) (CHILLOTTI et al., 2020a). Como a segurança do TFHE deriva da dificuldade desse problema (REGEV, 2005), e como o problema se mantém difícil, dentro do estado da arte atual, mesmo diante de ataques quânticos, segue que o TFHE é considerado um esquema resistente a ataques quânticos. Convém notar que o TFHE não é, ele próprio, um dos padrões pós-quânticos selecionados pelo NIST, que abrangem mecanismos de encapsulamento de chave e assinaturas digitais (como o Kyber e o Dilithium); ele compartilha com esses padrões, porém, a mesma família de dificuldade computacional (reticulados e LWE), da qual provém sua segurança.

Essa propriedade diferencia o TFHE das construções clássicas baseadas em RSA ou em curvas elípticas. Mesmo que um leilão executado com FHE seja registrado em uma blockchain pública e seus ciphertexts permaneçam disponíveis indefinidamente, eles não se tornarão decifráveis pela mera chegada de computadores quânticos. As assinaturas que autorizam transações na Ethereum, por contraste, são vulneráveis: chaves expostas hoje podem ser comprometidas no futuro.

2.4.4 Harvest Now, Decrypt Later

Essa diferença motiva uma classe de ataques chamada Harvest Now, Decrypt Later (HNDL). A ideia é simples: o adversário coleta dados cifrados hoje e os armazena, contando com o avanço futuro da computação quântica para decifrá-los. Para sistemas com vida útil curta, o risco é baixo. Para sistemas onde os dados precisam permanecer confidenciais por décadas, ou onde os registros são imutáveis e públicos, como em uma blockchain, o risco se torna substancial.

Mallick et al. (2025) e Ipsen (2026) discutem em detalhe essa classe de ataque no contexto específico de blockchains. Ipsen, em particular, ressalta que o desafio prático não é tanto a existência de algoritmos PQC, já em parte padronizados, mas a coordenação da migração em sistemas descentralizados que carecem de governança central e que não foram desenhados para agilidade criptográfica.

Para um leilão confidencial registrado on-chain, a propriedade quantum-resistant do TFHE oferece uma garantia adicional importante: o sigilo dos lances perdedores não tem prazo de validade ditado pela evolução da computação quântica. É uma propriedade que se soma às demais e que reforça o argumento em favor da arquitetura proposta neste trabalho.

2.5 Teoria de leilões

Esta seção fecha a fundamentação com a teoria de leilões: a tipologia básica (§2.5.1), a distinção entre formatos abertos e selados (§2.5.2), o arcabouço de mechanism design (§2.5.3), as regras formais do leilão de Vickrey (§2.5.4), a prova de truthfulness em alto nível (§2.5.5) e as razões pelas quais esse mecanismo importa para alocação justa (§2.5.6).

2.5.1 Tipologia básica

Um leilão é um mecanismo formal de alocação de bens escassos baseado em ofertas competitivas dos participantes. A literatura clássica identifica quatro formatos canônicos de leilão de uma única unidade, descritos em detalhe por Krishna (2009).

O leilão inglês (English auction, ou open ascending auction) é o formato mais familiar: o leiloeiro inicia o pregão com um preço-base e os participantes elevam suas ofertas em rodadas sucessivas; o último a ofertar vence e paga o valor de sua oferta. O leilão é aberto, no sentido de que cada lance é publicamente observado pelos demais participantes durante o pregão.

O leilão holandês (Dutch auction, ou open descending auction) é o oposto: o leiloeiro inicia com um preço alto que decai progressivamente, e o primeiro participante a aceitar o preço corrente vence, pagando esse valor. Também é aberto.

O leilão selado de primeiro preço (first-price sealed-bid auction) muda o paradigma. Cada participante submete uma única oferta cifrada (selada), sem conhecer as ofertas dos demais. Ao final, o leiloeiro abre todas as ofertas e o maior lance vence, pagando exatamente o valor que ofertou.

O leilão de Vickrey (second-price sealed-bid auction) é uma variação do anterior, com uma alteração que parece pequena mas tem consequências profundas: o maior lance vence, mas paga apenas o valor do segundo maior lance. Essa modificação foi proposta por Vickrey (1961), em artigo que rendeu, décadas depois, o Prêmio Nobel de Economia ao autor.

2.5.2 Sealed-bid versus open-cry

A distinção entre leilões abertos (open-cry) e selados (sealed-bid) é mais profunda do que parece à primeira vista. Em leilões abertos, cada participante toma decisões de forma sequencial, observando os lances dos concorrentes. Em leilões selados, cada participante decide isoladamente, sem essa observação.

Há uma equivalência teórica conhecida entre algumas dessas formas: o leilão inglês com lances pequenos é estrategicamente equivalente ao leilão de Vickrey, sob certas hipóteses, porque o vencedor acaba pagando, em média, o valor do segundo maior lance (o lance do segundo colocado, no momento em que ele desistiu). De forma análoga, o leilão holandês é estrategicamente equivalente ao leilão selado de primeiro preço, porque em ambos os casos o participante precisa decidir quanto está disposto a pagar sem conhecer os lances dos demais (KRISHNA, 2009).

Essas equivalências, porém, dependem de hipóteses que não são satisfeitas em ambientes adversariais como blockchains públicas, conforme discutido nos capítulos 2 e 6. Em particular, a propriedade que faz o leilão de Vickrey atraente, a truthfulness, pressupõe que os lances permaneçam efetivamente selados.

2.5.3 Mechanism design

A área de mechanism design estuda o desenho de regras de interação que induzem comportamentos socialmente desejáveis em ambientes onde os participantes têm informações privadas e perseguem interesses individuais. Aplicada a leilões, ela responde a perguntas como: que regra de pagamento maximiza a receita do leiloeiro? Que regra incentiva os participantes a revelar seus valores reais? Que regra é robusta contra colusão?

Krishna (2009) é a referência canônica para o tratamento moderno do tema. Os três pesquisadores que mais contribuíram com a fundamentação da área (Hurwicz, Maskin e Myerson) receberam o Prêmio Nobel de Economia em 2007. O conceito mais relevante para este trabalho é o de incentive-compatibility, ou truthfulness: uma regra é dita incentivo-compatível quando, para cada participante, a estratégia de revelar seu valor real é uma estratégia dominante, ou seja, é a melhor resposta independentemente do que os demais façam.

Mecanismos incentivo-compatíveis têm um apelo prático enorme: eles eliminam a necessidade de o participante calcular estratégias sofisticadas, reduzem o custo de participação e, em geral, produzem alocações mais eficientes. Quando aplicados a leilões, dão origem aos chamados leilões truthful, ou Dominant Strategy Incentive Compatible (DSIC).

2.5.4 Vickrey: regras formais

Para fixar a notação, considere um leilão de uma única unidade com $n$ participantes. Cada participante $i$ tem um valor privado $v_i$ que representa quanto o item vale para ele. Cada participante submete um lance $b_i$. A regra de Vickrey (VICKREY, 1961) é a seguinte:

1. Alocação: o item é alocado ao participante com o maior lance, isto é, $i^* = \arg\max_i b_i$ (a notação $\arg\max$ devolve o índice $i$ que maximiza o lance $b_i$).
2. Pagamento: o vencedor paga o segundo maior lance, isto é, $p = \max_{i \neq i^*} b_i$.

Em caso de empate no maior lance, alguma regra de desempate determinística (por exemplo, ordem de chegada) precisa ser adotada. Os participantes que não venceram não pagam nada.

2.5.5 Truthfulness e prova em alto nível

A propriedade central do leilão de Vickrey é o seguinte teorema (VICKREY, 1961; KRISHNA, 2009): para cada participante, ofertar exatamente seu valor real (ou seja, $b_i = v_i$) é uma estratégia fracamente dominante. Isso significa que, qualquer que seja o comportamento dos demais participantes, o resultado do participante $i$ ao ofertar $v_i$ é pelo menos tão bom quanto ao ofertar qualquer outro valor.

A prova procede por análise de casos. Considere um participante específico com valor $v$, e seja $p$ o maior lance entre os demais participantes (isto é, o segundo maior lance considerando todos, do ponto de vista desse participante).

Suponha que o participante decida ofertar $b > v$. Há três casos a considerar. Se $p < v$, o participante vence em ambos os cenários (ofertando $b$ ou ofertando $v$) e paga $p$ nos dois casos: o resultado é o mesmo. Se $p > b$, o participante perde em ambos os cenários: o resultado é o mesmo. Se $v < p < b$, o participante perde ao ofertar $v$ (resultado: zero) e vence ao ofertar $b$, mas paga $p$ por algo que vale apenas $v$: o resultado é negativo, ou seja, $v - p < 0$. Em nenhum cenário ofertar $b > v$ é estritamente melhor que ofertar $v$, e em pelo menos um cenário é estritamente pior.

Suponha agora que o participante decida ofertar $b < v$. Novamente há três casos. Se $p < b$, o participante vence em ambos os cenários e paga $p$: o resultado é o mesmo. Se $p > v$, o participante perde em ambos: o resultado é o mesmo. Se $b < p < v$, o participante perde ao ofertar $b$ (resultado: zero) e venceria ao ofertar $v$, pagando $p < v$ por algo que vale $v$: o resultado seria $v - p > 0$. Ofertar $b < v$ é estritamente pior nesse cenário e nunca é estritamente melhor.

Combinando os dois casos, ofertar $b = v$ nunca é pior que qualquer alternativa, e em alguns cenários é estritamente melhor. A estratégia $b = v$ é, portanto, fracamente dominante. O argumento depende criticamente da regra de pagamento (segundo preço): se o vencedor pagasse seu próprio lance, como em um leilão de primeiro preço, ofertar $v$ deixaria de ser ótimo, pois o participante teria incentivo a mascarar seu valor real para preservar margem.

2.5.6 Por que Vickrey importa para alocação justa

A propriedade de truthfulness tem consequências práticas relevantes em três frentes. Primeiro, simplifica enormemente o cálculo estratégico do participante: basta declarar o valor real, sem necessidade de modelar o comportamento dos demais. Segundo, garante uma alocação eficiente em sentido econômico, ou seja, o item vai ao participante que mais o valoriza, o que maximiza o bem-estar agregado (KRISHNA, 2009). Terceiro, é robusta a informação assimétrica: ainda que os participantes tenham níveis muito diferentes de informação sobre o ativo leiloado, todos têm interesse em revelar seus valores reais.

Por essas razões, o leilão de Vickrey ocupa um lugar privilegiado na teoria e em aplicações práticas. Plataformas de publicidade online, sistemas de alocação de espectro, mercados institucionais e várias outras situações de alocação competitiva inspiram-se direta ou indiretamente nele. A condição que sustenta esses casos é, contudo, que os lances permaneçam efetivamente selados. Quando essa condição falha, o mecanismo perde a propriedade de truthfulness. O uso de FHE neste trabalho responde a essa falha.

Cabe explicitar, por fim, por que é a regra do segundo preço, e não a do primeiro, que torna o mecanismo interessante. Em um leilão de primeiro preço, o vencedor paga o que ofertou, e por isso tende a ofertar abaixo de seu valor real para preservar margem (prática conhecida como bid shading); o lance deixa de revelar a valoração verdadeira. O segundo preço remove esse incentivo, pois o valor pago não depende do próprio lance, e é isso que faz da verdade a estratégia ótima. Essa inversão sutil é a contribuição que rendeu a Vickrey o Prêmio Nobel de Economia. Para este trabalho, ela importa por duas razões somadas: economicamente, é a regra cuja utilidade mais depende do sigilo dos lances, e que portanto mais é prejudicada pela transparência on-chain; tecnicamente, é o cálculo do segundo maior valor sem revelar o vencedor que origina o problema da exclusão (§4.2.2), o desafio central da implementação deste trabalho.

2.6 Síntese

Os cinco corpos de conhecimento apresentados ao longo deste capítulo se articulam de modo direto na solução proposta pelo trabalho. A blockchain pública (§2.1) é a infraestrutura sobre a qual o leilão é executado, e cuja transparência pública cria o problema central. A criptografia clássica (§2.2) fornece as primitivas (assinaturas, hashes) que sustentam a operação básica da rede e que são insuficientes para proteger lances. A FHE, em particular o TFHE realizado pela Fhenix CoFHE (§2.3), fornece a ferramenta que torna possível executar o cálculo do mecanismo sobre dados cifrados. A propriedade de resistência quântica do TFHE (§2.4) reforça a robustez de longo prazo da garantia de sigilo. E a teoria de leilões (§2.5) fornece o mecanismo de Vickrey, com sua propriedade de truthfulness, que define o que precisa ser computado e por que essa propriedade é essencial.

Os capítulos seguintes mobilizam esses elementos de forma específica. O capítulo 3 situa este trabalho em relação à literatura. O capítulo 4 desenvolve o trabalho em quatro blocos integrados: a §4.1 formaliza o problema e o modelo de ameaça, a §4.2 detalha a solução proposta, em especial o tratamento do problema da exclusão, a §4.3 especifica e modela o sistema, a §4.4 descreve a implementação concreta do contrato e da interface gráfica, e a §4.5 consolida as garantias obtidas pela arquitetura. O capítulo 5 apresenta a metodologia de avaliação, os resultados coletados e a discussão correspondente.