Avaliação e Discussão

Este capítulo avalia a implementação descrita no capítulo 4 sob os três eixos definidos para o trabalho (custo computacional, latência e privacidade), acrescidos de uma análise de robustez, e discute os trade-offs, as limitações e as ameaças à validade. Apresenta a metodologia de avaliação (§5.1), o custo computacional (§5.2), a latência (§5.3), a análise quantitativa de privacidade e vazamento (§5.4), a robustez (§5.5) e, por fim, a discussão consolidada (§5.6).

Como mapa de leitura, a tabela 12 relaciona cada parte da hipótese H (§1.4) à evidência que este capítulo apresenta para sustentá-la.

Tabela 12: Mapeamento entre as partes da hipótese e as evidências apresentadas.

5.1 Metodologia de avaliação

A avaliação foi conduzida sobre populações sintéticas de participantes em três tamanhos, N ∈ {3, 5, 10}, com pelo menos cinco repetições por configuração, totalizando 240 medições no mock e 345 na testnet pública. No mock, as 240 medições correspondem a 60 medições de operações de instância única por leilão (sob 15 execuções: três tamanhos de N por cinco repetições) e 180 medições de operações por participante (lance e retirada, uma medição por licitante em cada execução); a testnet replica essas 240 medições de gás on-chain e acrescenta 105 medições off-chain de latência (cifração no cliente e decifração via TSN), chegando a 345. A escolha de N cobre desde o mínimo viável do mecanismo (MIN_BIDDERS = 3, conforme §4.2.5) até a escala de pequenos a médios leilões institucionais assumida pela hipótese do trabalho. As repetições permitem observar a dispersão das medidas, sobretudo na testnet, em que fatores de rede introduzem variação entre execuções. Nas figuras deste capítulo, essa dispersão aparece como barras de erro de ±1 desvio-padrão; no mock, cujas operações são quase determinísticas, as barras são imperceptíveis.

As medições foram feitas em dois ambientes complementares, descritos na tabela 13. Cada um responde a uma pergunta diferente: o mock isola o custo algorítmico (sem a taxa de dados da camada 1, o custo que uma rede de camada 2 como a Arbitrum paga para registrar seus dados na blockchain base, conforme a noção de rollup da §3.2, nem a rede de decifração), enquanto a testnet mede o custo e a latência reais em uma blockchain pública.

Tabela 13: Ambientes de avaliação e o que cada um mede.

As métricas coletadas são quatro: o gás por operação (createAuction, bid, requestSettlement, finalizeSettlement, withdraw), o gás total ponta-a-ponta de um ciclo completo, o tamanho de calldata de cada transação, e a latência (tempo de parede, wall time) de cada fase, incluindo as etapas off-chain de cifração no cliente e de decifração via TSN. Essas etapas off-chain foram executadas e medidas na máquina cliente que orquestrou os experimentos (um MacBook com processador Apple M2 e 8 GB de RAM), pelo script de benchmark em Node.js (versão 20 ou superior), usando a mesma biblioteca TFHE compilada para WebAssembly que a interface gráfica emprega no navegador. Os dados brutos coletados (um arquivo em formato CSV para o mock e outro para a testnet) e o script que os processa para gerar os gráficos deste capítulo estão disponíveis no repositório público do projeto (§4.4.1), de modo que todas as medições e figuras possam ser reproduzidas.

5.2 Custo computacional

A tabela 14 apresenta o gás médio por operação na testnet Arbitrum Sepolia, discriminado por N. A operação bid é, de longe, a mais cara, por concentrar a aritmética homomórfica do trabalho (o cap mais a atualização top-2, descritos em §4.2.3 e §4.2.5); a figura 11 torna visível essa diferença de magnitude entre as operações. As demais operações são substancialmente mais baratas, porque manipulam apenas autorizações de ACL, verificações de prova ou transferências de ETH.

Tabela 14: Gás médio por operação na Arbitrum Sepolia, por número de participantes.

Uma leitura apressada da tabela 14 sugeriria que o custo cresce com N, o que tensionaria a afirmação de custo por operação constante (RNF-05, §4.2.3). O ponto, contudo, é que a testnet mistura o custo algorítmico com a taxa de dados da camada 1 da Arbitrum, que varia entre execuções, e com um efeito de inicialização discutido adiante. Para isolar o custo algorítmico, recorre-se ao mock, que não tem taxa L1. A tabela 15 mostra o gás no mock, e o resultado é nítido: para requestSettlement, finalizeSettlement e os dois withdraw, o gás é praticamente idêntico entre N = 3, N = 5 e N = 10 (desvios de poucas unidades de gás), e o bid varia menos de dois por cento. O custo por operação é, portanto, constante em N, como prevê o padrão top-2 incremental, e a figura 12 evidencia essa constância no formato de linhas aproximadamente horizontais.

Tabela 15: Gás médio por operação no mock, por número de participantes. A constância entre colunas evidencia o custo O(1) em N.

Dois fenômenos do custo merecem explicação. O primeiro é que o mock é mais caro que a testnet na operação bid (cerca de 1,65 milhão contra 611 mil de gás, em média entre as três populações). Isso decorre da arquitetura do CoFHE: na testnet, parte da computação homomórfica é delegada ao coprocessador off-chain (§4.2.1), de modo que o gás on-chain reflete sobretudo a gestão simbólica de handles; no mock, as operações FHE são simuladas integralmente on-chain, o que infla o gás contabilizado. Assim, os números do mock servem para comparar operações entre si e verificar a invariância em N, mas o custo real de produção é o da testnet. O segundo fenômeno é o efeito do primeiro lance: o lance de índice 0 de cada leilão é sensivelmente mais barato (cerca de 1,51 milhão de gás no mock, contra cerca de 1,68 milhão dos lances seguintes), porque inicializa pela primeira vez o estado cifrado do top-2, ao passo que os lances subsequentes executam a comparação homomórfica completa. Esse efeito, e não uma dependência de N, é o que faz a média do bid subir ligeiramente em leilões maiores.

Embora o custo por operação seja constante em N, o custo total de um leilão cresce de forma aproximadamente linear, simplesmente porque um leilão com N participantes contém N transações de bid e N de withdraw. A tabela 16 e a figura 13 quantificam esse total ponta-a-ponta.

Tabela 16: Gás total de um ciclo completo do leilão (criação, N lances, settlement e N+1 saques).

Quanto ao tamanho de calldata, apenas a operação bid carrega um payload não-trivial: 324 bytes, correspondentes à estrutura InEuint64 (o lance cifrado mais os metadados de prova). As demais transações têm calldata mínima, pois recebem apenas identificadores e endereços. Os 324 bytes do lance cifrado são cerca de uma ordem de grandeza maiores que os 32 bytes de um lance em texto claro, o que ilustra o custo de transmissão da confidencialidade. Por fim, sobre o cap homomórfico introduzido em §4.2.5: ele acrescenta três operações FHE por bid (uma FHE.asEuint64, uma FHE.gt e uma FHE.select); como o bid já executa seis operações FHE no caminho do top-2, o cap representa um acréscimo modesto sobre uma operação que, de todo modo, é a mais cara do contrato.

Custo em moeda corrente. Os números de gás ganham concretude quando convertidos para moeda, ainda que a conversão seja um retrato datado: tanto o preço do gás quanto o câmbio flutuam. Tomando o custo de gás medido na testnet como aproximação do custo na rede principal da Arbitrum (Arbitrum One, que usa a mesma arquitetura de cobrança), o preço de gás de 0,02 gwei consultado em 18 de julho de 2026 no RPC público oficial da rede¹ e a cotação do ETH no mesmo dia (US$ 1.841 e R$ 9.440, cf. COINGECKO, 2026), a operação de lance, de cerca de 611 mil unidades de gás, custa aproximadamente 0,000012 ETH, ou seja, cerca de US$ 0,02 (R$ 0,12); e um ciclo completo de leilão custa de US$ 0,10 (R$ 0,52) com três participantes a US$ 0,31 (R$ 1,58) com dez, somadas todas as transações de todos os papéis. Como referencial de escala, a menor transação possível em uma rede compatível com a EVM, a transferência simples de ETH, tem custo intrínseco de 21 mil unidades de gás, constante definida pelo protocolo da Ethereum (WOOD, 2014) e herdada pela Arbitrum como piso de execução; o lance cifrado consome cerca de 29 vezes esse piso. A comparação com um lance em texto claro permanece qualitativa, conforme discutido na §5.6. Em termos absolutos, o custo da confidencialidade é da ordem de centavos de dólar por participante nas condições atuais da Arbitrum One, o que reforça a compatibilidade do mecanismo com leilões de alto valor unitário.

5.3 Latência

A latência foi medida na testnet em três naturezas distintas: as confirmações on-chain, a cifração no cliente e o round-trip de decifração com a TSN. A tabela 17 e a figura 14 resumem os tempos médios por fase.

Tabela 17: Latência média por fase na Arbitrum Sepolia.

O dado mais relevante é que a cifração no cliente (cerca de 6,8 segundos em média, com observações entre 6,1 e 11,3 segundos) é o maior componente isolado de latência percebida pelo usuário, superando qualquer transação on-chain. Isso é coerente com a natureza do TFHE (§2.3.1): cifrar um valor e gerar a prova de boa-formação em WebAssembly é computacionalmente pesado, seja no navegador, seja em Node.js. As confirmações on-chain ficam todas na faixa de 2,3 a 2,7 segundos, refletindo o tempo de bloco da Arbitrum. O round-trip da TSN, na fase de revelação, custa cerca de 2,9 segundos, com baixa dispersão (entre 2,8 e 3,1 segundos), o que indica que a rede de decifração respondeu de forma estável durante os experimentos.

Em termos de experiência ponta-a-ponta, um participante que submete um lance espera tipicamente a soma da cifração e da confirmação, isto é, cerca de nove a dez segundos. A finalização do leilão, orquestrada pelo cliente (§2.3.5), envolve a consulta à TSN seguida da transação finalizeSettlement, somando cerca de cinco a seis segundos. Esses tempos são compatíveis com um fluxo interativo, ainda que a cifração WASM seja o gargalo a observar em otimizações futuras.

5.4 Privacidade e vazamento de informação

Esta seção quantifica o que o adversário definido em §4.1.2 consegue inferir sobre os lances após o encerramento do leilão. A tabela de capabilities por estado já foi apresentada em §4.1.5; aqui o foco é a incerteza residual sobre os valores dos lances no estado terminal Settled, derivada em forma fechada.

Sejam C o colateral uniforme (teto público dos lances, conforme §4.2.5) e p o segundo maior lance, que é revelado ao final. Após a finalização, o adversário conhece a identidade do vencedor e o valor p, e nada mais sobre os valores individuais. A partir disso, o conjunto de valores ainda compatível com o observado, para cada categoria de lance, é o seguinte:

• Lance do vencedor: está em [p, C]. É maior ou igual a p (pois é o maior lance) e menor ou igual a C (pelo cap homomórfico). A incerteza residual é a largura C − p.
• Segundo maior lance: é exatamente p. Incerteza residual nula (é o único valor revelado).
• Cada um dos N − 2 lances restantes: está em [0, p], pois é menor ou igual ao segundo maior. A incerteza residual de cada um é a largura p.

Modelando a crença do adversário como uma distribuição uniforme sobre cada intervalo compatível, e medindo as larguras no domínio discreto dos valores representáveis (inteiros do tipo euint64, limitados pelo cap C), a incerteza residual de um valor uniforme sobre w valores compatíveis é a entropia de Shannon, isto é, a medida formal de quanta incerteza resta, igual a log₂(w) bits, sempre não negativa (no caso-limite de um único valor compatível, w = 1, ela é nula). Na ilustração adiante, os valores em ETH expressam proporções do domínio; para a contagem de bits, as larguras são convertidas ao domínio discreto subjacente, em wei. A entropia residual total sobre o vetor de lances é, então, aproximadamente:

H_residual ≈ log₂(C − p)  +  (N − 2) · log₂(p)

em que a primeira parcela é a incerteza sobre o lance do vencedor e a segunda é a soma das incertezas sobre os N − 2 lances perdedores de menor valor.

Duas premissas sustentam essa medida e devem ser explicitadas. A primeira, já adotada acima, é a crença uniforme: a incerteza do adversário sobre cada intervalo compatível é modelada por uma distribuição uniforme, que é a de entropia máxima sobre um suporte limitado. A segunda é a independência entre lances: a entropia total é tomada como a soma das entropias por lance. Como a entropia conjunta nunca excede a soma das entropias marginais, e como a uniforme maximiza a entropia sobre cada intervalo, os valores reportados são um limite superior da incerteza residual: um adversário com crenças informativas, ou que explore a dependência de ordenação entre os lances perdedores (todos menores ou iguais a p), enfrentaria incerteza igual ou menor.

A tabela 18 resume essas categorias.

Tabela 18: Incerteza residual do adversário sobre os lances, no estado Settled.

A título de ilustração, considere o leilão de demonstração cujo painel de resultado aparece na Figura 10: colateral C = 0,01 ETH, três participantes e segundo preço revelado p = 0,0002 ETH. O lance do vencedor permanece confinado ao intervalo [0,0002; 0,01] ETH, uma faixa que cobre 98% da amplitude do domínio de lances; e o lance perdedor restante permanece em [0; 0,0002] ETH, uma faixa de 2% da amplitude. Instanciando a equação da entropia no domínio discreto em que os lances são representados (euint64, valores em wei, com C = 10¹⁶ wei), a incerteza a priori sobre cada lance é log₂(10¹⁶) ≈ 53,2 bits. Após a liquidação, a incerteza sobre o lance do vencedor é log₂(C − p) = log₂(9,8×10¹⁵) ≈ 53,1 bits, e a sobre o perdedor restante é log₂(p) = log₂(2×10¹⁴) ≈ 47,5 bits; a entropia residual total é H_residual ≈ 53,1 + 47,5 ≈ 100,6 bits, de um máximo a priori de 2 × 53,2 ≈ 106,3 bits sobre os dois lances não revelados, ou seja, cerca de 95% da incerteza original sobrevive. Note que mesmo o intervalo proporcionalmente estreito do perdedor (2% da amplitude) ainda contém cerca de 2×10¹⁴ valores possíveis: proporção pequena não significa incerteza pequena. Num leilão totalmente público, por contraste, todas essas entropias seriam nulas: cada lance seria conhecido exatamente. É essa distância, entre cerca de cem bits residuais e zero, que a medida quantifica: a revelação exigida pela regra de Vickrey colapsa exatamente um valor a um ponto (o segundo preço) e a identidade do vencedor, consumindo poucos bits de todo o resto, o que sustenta empiricamente os objetivos de privacidade enunciados em §4.1.3 e, por consequência, a propriedade de truthfulness (§2.5.5).

5.5 Robustez

A robustez do sistema é analisada sob quatro vetores, em linha com as limitações declaradas em §4.1.6.

Censura no nível do mempool. A FHE protege o conteúdo da transação, não a sua inclusão. Um validador ainda pode observar que um endereço enviou uma transação bid (ainda que não saiba o valor) e se recusar a incluí-la, ou atrasá-la. Esse vetor não é eliminado pela confidencialidade; mitigações como mempools privados (Flashbots Protect, §1.2.2) reduzem a exposição, mas a defesa completa contra censura de consenso está fora do escopo. O modelo assume liveness razoável da rede subjacente.

Indisponibilidade da TSN. Como a revelação depende da cooperação de um quórum de operadores da TSN (§4.1.4), uma indisponibilidade da rede de decifração deixaria o leilão preso no estado SettlementRequested, sem conseguir transitar para Settled. É importante notar que, mesmo nesse cenário, a confidencialidade é preservada: os handles não se tornam decifráveis por outro meio. Mitigações possíveis incluem re-tentativa e um timeout configurável; um desligamento permanente da TSN tornaria os handles não-decifráveis para sempre, preservando o sigilo às custas da finalização. Há também uma consequência patrimonial direta, verificada no contrato: como withdraw exige os estados Settled ou Cancelled e cancelAuction exige Active, um leilão preso em SettlementRequested mantém os colaterais bloqueados. Uma via de escape por timeout, em que o decurso de um prazo sem finalização habilita a devolução integral dos colaterais sem revelar resultado algum, é uma extensão natural do contrato.

Dependência de infraestrutura, continuidade e custos. A dependência da plataforma merece ser separada em duas camadas. O contrato em si é Solidity padrão e reside na própria blockchain; o que depende da Fhenix são o coprocessador CoFHE, que executa as operações sobre os tipos cifrados e armazena os ciphertexts, e a TSN, que detém coletivamente a chave de decifração (§2.3.4). Um desligamento permanente dessas camadas não afeta a validade dos leilões já liquidados, cujo resultado é estado público da blockchain, mas interromperia os leilões em curso: sem o coprocessador não há como processar novos lances, e sem a TSN não há como revelar resultados, no cenário discutido acima. Tampouco existe um caminho de migração para os dados cifrados: como decifrá-los exige a chave da TSN, os ciphertexts não podem ser re-cifrados para outra infraestrutura, e a portabilidade se restringe à lógica do mecanismo, conceitualmente aplicável a plataformas FHE equivalentes, como a fhEVM da Zama (§2.3.4), ao custo de adaptação do sistema e do modelo de decifração. Por fim, há uma dimensão de custo além do gás: a operação do coprocessador e da TSN é mantida pela própria Fhenix, sem cobrança ao usuário além do gás medido, e, como a plataforma ainda se encontrava em fase de testnet à época deste trabalho, não existia modelo de precificação dessas camadas para produção. Os custos medidos neste capítulo refletem, portanto, apenas a componente on-chain; uma implantação comercial precisará orçar também a infraestrutura FHE quando esta alcançar a rede principal. Essas dependências são o preço arquitetural da terceirização da computação cifrada, e explicitá-las é parte do compromisso metodológico do trabalho.

Vencedor não-cooperante. Um risco clássico em leilões selados é o do vencedor que, ao descobrir que venceu, se recusa a concluir a transação. Aqui esse risco é estruturalmente neutralizado: tanto requestSettlement quanto finalizeSettlement são permissionless (§4.3.4), de modo que qualquer participante pode encerrar e finalizar o leilão após o prazo, sem depender da cooperação do vencedor. O vencedor também não pode travar a liquidação dos demais, pois o modelo de pagamento é pull (§4.2.5): cada participante saca independentemente.

O incidente do shill bidding. Durante os smoke tests na testnet, observou-se um vetor que não havia aparecido no mock: o seller submeteu, por engano, um lance ao próprio leilão. Como o mecanismo aceita lances de qualquer endereço, o lance foi processado, e o colateral do seller ficou contabilmente preso no contrato, sem um caminho de saque consistente com os papéis previstos na função withdraw. O episódio motivou duas correções defensivas, ambas descritas em §4.2.5: a proibição explícita de o seller dar lances (SellerCannotBid) e o reforço do cap homomórfico. O caso é instrutivo porque ilustra o valor de testar em testnet pública, e não apenas no mock: certos vetores de falha só se manifestam sob condições reais de uso, com múltiplas carteiras e papéis distintos interagindo.

5.6 Discussão: trade-offs, limitações e ameaças à validade

Os resultados anteriores permitem discutir os trade-offs centrais do trabalho, suas limitações e as ameaças à validade das conclusões.

Trade-offs. O custo da confidencialidade é mensurável e concentrado. Em gás, ele se manifesta sobretudo na operação bid, cerca de uma ordem de grandeza mais cara que um lance em texto claro, e no calldata, também cerca de dez vezes maior. Em latência, manifesta-se na cifração WASM no cliente, o maior componente de tempo percebido. Em contrapartida, o sistema entrega uma propriedade que nenhum leilão on-chain convencional oferece: o sigilo permanente de todos os lances exceto o segundo preço, com truthfulness preservada e sem leiloeiro confiável. Para os casos de uso que motivam o trabalho, em que o vazamento de estratégia tem custo econômico real (§1.2), esse é um trade-off favorável. Registre-se que essa avaliação de favorabilidade é qualitativa: as referências a um lance em texto claro ou a um esquema commit-reveal são pontos de comparação de ordem de magnitude, não baselines implementados e medidos lado a lado sob a mesma metodologia. A medição controlada desses baselines fica como trabalho futuro (§6.3).

Limitações. Seis limitações devem ser explicitadas. Primeiro, a avaliação cobre N ≤ 10; leilões com centenas de participantes não foram medidos, e o custo total cresce linearmente com N. Segundo, o trabalho implementa o caso de unidade única; a extensão multi-unit fica como trabalho futuro (capítulo 6). Terceiro, os números de gás do mock e da testnet diferem por construção (o mock simula a FHE on-chain), de modo que apenas os valores da testnet representam custo de produção. Quarto, a identidade dos participantes e o teto público C permanecem visíveis, conforme já reconhecido em §4.1.6. Quinto, a truthfulness do mecanismo é condicional ao pressuposto de que o valor verdadeiro de cada participante não excede o colateral público exigido (v ≤ C). O cap homomórfico (§4.2.5) trunca ao colateral qualquer lance acima de C, de modo que um participante com v > C tem seu lance efetivo reduzido a C e não consegue revelar v, no padrão clássico de participante com restrição de orçamento. Para todo participante com v ≤ C, a estratégia dominante de declarar o valor verdadeiro permanece preservada; o cap é o preço pago pela garantia de que o vencedor sempre pode honrar o pagamento (§4.2.5). Sexto, o modelo de colateral é integral e em ETH nativo: cada participante imobiliza o valor máximo C durante todo o leilão, ainda que pretenda ofertar menos, e o faz em um ativo volátil. A escolha é deliberada, pois um colateral proporcional ao lance vazaria o próprio lance por meio do depósito público, e o colateral uniforme é justamente o que impede essa inferência (§4.2.5); mas ela cria uma barreira prática de entrada (quem não dispõe do colateral não participa) e um custo de oportunidade sobre o capital imobilizado, relevantes para a adoção do mecanismo em cenários reais. Alternativas são discutidas como trabalho futuro (§6.3).

Ameaças à validade. A principal ameaça à validade interna é a variação da taxa de dados L1 da Arbitrum entre execuções, que introduz ruído nos números de gás da testnet; ela foi mitigada pela repetição das medições e pelo uso do mock como referência algorítmica. A principal ameaça à validade externa é o número reduzido de repetições (cinco por configuração) e a natureza sintética das populações de lances, escolhas conscientes diante do custo de gás em testnet; os resultados devem ser lidos como ordens de grandeza representativas, não como estimativas estatísticas de alta precisão. Por fim, a avaliação se dá em uma única plataforma (Fhenix CoFHE sobre Arbitrum Sepolia), o que limita a generalização para outras infraestruturas de FHE on-chain.

Aderência aos critérios de sucesso. Confrontando os resultados com os critérios definidos no escopo (§1.6): o sistema foi validado ponta-a-ponta em testnet pública, pela interface gráfica, em demonstrações operando a partir do mínimo exigido pelo contrato (MIN_BIDDERS = 3, cf. §4.4.4), e, pelo benchmark, nas populações de 3, 5 e 10 participantes definidas no escopo (§1.6); a suíte de vinte testes cobre os cenários críticos enumerados (§4.4.5); a análise de vazamento foi formalmente estruturada, com modelo de adversário (§4.1), tabela de capabilities (§4.1.5) e métrica de incerteza residual (§5.4); e a documentação foi disponibilizada para reprodução por terceiros (§4.4.1). Os quatro critérios foram, portanto, atendidos. O capítulo seguinte conclui o trabalho e discute as direções de extensão abertas por estes resultados.