FHE se lanza en producción: ERC-7984 y el límite de throughput

Introducción

Una transferencia ERC-20 publica el monto movido y los balances resultantes de ambas partes a cualquiera con acceso a un endpoint RPC. Para una nómina, un rebalanceo de tesorería o una operación de bloque, esa propiedad es descalificante, y la solución habitual ha sido mantener la transacción fuera de la cadena, liquidando solo un resultado neto.

El Protocolo de Blockchain Confidencial de Zama propone un arreglo distinto. Según su litepaper, se trata de una capa de confidencialidad cross-chain que se sitúa sobre blockchains públicas existentes en lugar de ser una nueva L1 o L2, combinando cifrado totalmente homomórfico para computar sobre valores cifrados, computación multipartita para la gestión de claves por umbral, y pruebas de conocimiento cero usadas de forma acotada para verificar que las entradas del usuario fueron cifradas correctamente. La hoja de ruta declarada puso el testnet en vivo antes de la publicación del litepaper, la mainnet de Ethereum a fines de 2025, otras cadenas EVM en el primer semestre de 2026, y Solana en el segundo semestre de 2026. La explicación de Zama sobre ERC-7984, el estándar de token confidencial, tiene fecha del 17 de febrero de 2026 y describe el estándar como agnóstico a la tecnología, con la implementación FHE construida en conjunto con OpenZeppelin.

Varias cifras asociadas a este lanzamiento en comentarios de mercado no aparecen en la documentación primaria: un throughput actual de aproximadamente 20 transacciones por segundo, un objetivo de 500 a 1.000 transacciones por segundo tras el despliegue de GPU, volúmenes de despliegue en USDC confidencial, una operación OTC institucional específica, la mecánica y fecha de un evento del token $ZAMA, y el estado de auditoría de la implementación ERC-7984 de OpenZeppelin. No pudimos verificar ninguno de estos datos contra el litepaper de Zama, su explicación de ERC-7984, ni la documentación de Fhenix e Inco. Permanecen sin confirmar, y el análisis razona a partir de lo que declaran los documentos del proveedor.

La criptografía es la parte madura de este stack. Tres costuras cargan el peso en su lugar: la brecha entre lo que registra el contrato onchain y lo que computa una red de coprocesadores offchain, la vía asíncrona por la cual un valor cifrado se convierte en texto plano, y el comité de nodos que en conjunto sostiene la clave de descifrado.

El costo de la aritmética que nadie puede ver

El cifrado totalmente homomórfico permite que una parte que solo posee textos cifrados compute una función sobre ellos, produciendo un texto cifrado del resultado, sin conocer las entradas ni la salida. Aplicado a un token, una suma sobre dos balances cifrados produce un nuevo balance cifrado, y la máquina que ejecuta esa suma no conoce ninguno de los dos operandos.

El sobrecosto es estructural. Los textos cifrados FHE en esquemas basados en retículas son mucho más grandes que los textos planos que ocultan, y cada operación homomórfica añade ruido al texto cifrado. Superado un umbral, el ruido destruye el valor, así que los esquemas ejecutan periódicamente un paso de reducción de ruido que es en sí mismo el costo dominante de la computación. Zama afirma que su implementación es más de 100 veces más rápida que hace cinco años y que es segura post-cuántica, esto último derivado de los supuestos de retículas sobre los que descansan estos esquemas. Ambas son afirmaciones del proveedor provenientes de un documento propio sin benchmark independiente.

La restricción más relevante para quienes escriben contratos es el flujo de control. Un programa no puede ramificarse según una condición cifrada, porque tomar una rama revela cuál rama se tomó, y observadores que miden el consumo de gas o los patrones de acceso al estado descubrirían el resultado de la comparación que el cifrado buscaba ocultar. Los condicionales se convierten entonces en aritmética: se evalúan ambos resultados y un bit selector cifrado multiplexa entre ellos. Una transferencia confidencial cuesta lo mismo si el emisor tiene saldo suficiente o no, y produce una transición de estado en ambos casos.

Esa única propiedad se propaga por todo el diseño. Determina cómo maneja ERC-7984 una transferencia fallida, por qué la lógica de liquidación resulta incómoda de expresar, y por qué la brecha entre el costo de ejecución confidencial y en texto plano es un múltiplo y no un margen. La documentación de CoFHE de Fhenix expone la misma forma en su superficie de API, con tipos cifrados como euint32 y ebool, operaciones como FHE.add y FHE.sub, y llamadas explícitas de control de acceso como FHE.allowThis y FHE.allowSender que gobiernan quién puede descifrar un valor más adelante. El permiso para descifrar no es ambiente en estos sistemas. Es una concesión explícita que un contrato debe ejecutar; omitirla deja un valor permanentemente ilegible.

Handles, coprocesadores y un gateway

La explicación de Zama sobre ERC-7984 describe una arquitectura de cuatro partes, y la división del trabajo entre ellas es donde se concentra el riesgo de ingeniería.

El contrato onchain almacena handles cifrados, que son punteros a valores cifrados y no los textos cifrados en sí. Cuando un contrato de token confidencial suma dos balances cifrados, la transacción de Ethereum no ejecuta aritmética de retículas. Registra que debe realizarse una suma que relaciona tres handles y devuelve inmediatamente el handle de salida. El almacenamiento del contrato y el costo de gas de la transacción reflejan contabilidad sobre handles, no el costo de la criptografía.

La aritmética FHE real ocurre fuera de la cadena, en una red de coprocesadores que consumen las operaciones registradas y materializan los textos cifrados correspondientes. Un Gateway orquesta esos coprocesadores, impone el control de acceso sobre qué dirección puede leer qué handle, y enruta las solicitudes de descifrado. El descifrado en sí lo realiza un sistema de gestión de claves por umbral en el que múltiples nodos independientes deben cooperar, de modo que ningún operador individual pueda recuperar unilateralmente el balance de un usuario.

De esta división se desprenden dos propiedades directamente. Primero, la liquidación onchain finaliza más rápido que la computación cifrada que hay detrás. Una transferencia se confirma cuando la contabilidad de handles queda incluida en un bloque, pero el texto cifrado al que apunta ese handle existe solo una vez que un coprocesador lo ha producido. El modo de falla natural bajo carga es entonces un rezago: el estado simbólico avanza al ritmo de Ethereum mientras la materialización se atrasa, y la demora se manifiesta en el momento en que alguien pide leer un valor. Cualquier cosa que necesite una respuesta en texto plano, incluyendo a un usuario que revisa su balance o un contrato que espera un callback de descifrado, hereda esa cola.

Segundo, el componente ZK hace mucho menos trabajo aquí que en un pool blindado. Las pruebas de conocimiento cero se usan para establecer que una entrada enviada por el usuario fue cifrada correctamente y está vinculada a quien la envía, no para probar que alguna transición de estado se ejecutó correctamente. Un texto cifrado malformado o creado de forma adversarial que sea aceptado en el sistema podría corromper la computación posterior o convertirse en un canal para sondear la clave de la red, así que la prueba funciona como un filtro de entrada. En un pool blindado con zk-SNARK, la prueba lleva todo el argumento de corrección y el estado cifrado nunca es computado por un tercero. Son arquitecturas de seguridad distintas que casualmente comparten una sigla.

Zama afirma que las cadenas existentes no requieren ninguna actualización a nivel de protocolo para soportar este arreglo. Esa afirmación es acotada y arquitectónicamente plausible: la ejecución ocurre ya sea en el código del contrato o fuera de la cadena. No establece si las aplicaciones existentes pueden consumir el estado resultante.

Lo que ERC-7984 cambia dentro del contrato

A nivel de código, el estándar es una sustitución de tipos con consecuencias. Donde ERC-20 expone uint256, transfer y balanceOf, ERC-7984 expone euint64, confidentialTransfer y confidentialBalanceOf. Las operaciones lógicas sobreviven; los operandos se vuelven handles cifrados que el propio contrato no puede leer.

La reducción de 256 bits a 64 no es cosmética. El costo de FHE escala con el ancho de bits del entero cifrado, así que un token confidencial paga directamente por cada bit de rango que no usa. Un balance de 64 bits no puede representar un suministro de 18 decimales de cualquier tamaño, lo que empuja a los tokens confidenciales hacia menos decimales y un suministro máximo menor que sus contrapartes transparentes. Cualquier wrapper que conecte un ERC-20 existente de 18 decimales con una representación confidencial tiene que definir una convención de escala y aceptar el redondeo que introduce.

El manejo de saldo insuficiente es el segundo cambio estructural, y se deriva de la restricción de no ramificación. Un ERC-20 convencional revierte cuando el emisor carece de fondos, y esa reversión es información pública. Una transferencia confidencial no puede revertir sobre una comparación cifrada sin filtrar el resultado de la comparación a los observadores. El diseño computa un monto transferido cifrado que equivale al monto solicitado cuando los fondos son suficientes y a cero cuando no lo son, dejando que la transacción tenga éxito en ambos casos. Quienes llaman al contrato solo se enteran de lo ocurrido al descifrar el valor devuelto, si tienen permiso para hacerlo. Cada integración que trata una transacción exitosa como prueba de una transferencia completada requiere revisión.

Divulgación selectiva como función del contrato

La implementación de Zama aborda los requisitos de cumplimiento mediante Observers, direcciones como auditores o reguladores a quienes se les puede conceder acceso de descifrado sobre valores específicos, junto con módulos de extensión opcionales para verificaciones KYC y AML, congelamiento de balances, y reglas de cumplimiento para activos del mundo real. La divulgación opera como una concesión de permiso más que como valor por defecto, impuesta por el control de acceso del Gateway y no por discreción del operador.

Este diseño representa el núcleo de la propuesta institucional, y también la sección con menos detalle publicado. Si una concesión de Observer es revocable, si aplica prospectiva o retroactivamente a handles creados antes de la concesión, y quién puede emitir una en nombre de un usuario son preguntas de gobernanza que la documentación disponible no resuelve. Un módulo de congelamiento en particular reintroduce a un actor privilegiado en un sistema cuya premisa es que ningún actor privilegiado puede ver el estado del usuario. Esas dos propiedades son compatibles en principio, ya que el congelamiento actúa sobre handles sin leerlos, pero la combinación requiere verificación en el código del contrato y no solo en especificaciones de funciones.

Dónde los balances cifrados se encuentran con el DeFi existente

La afirmación de que Ethereum no necesita una actualización es distinta de la afirmación de que Uniswap o Aave pueden sostener tokens ERC-7984. La segunda afirmación es más difícil, impulsada por los mecanismos detallados arriba.

Un AMM de producto constante fija el precio de un swap a partir de reservas públicas. Si las reservas están cifradas, el pool no puede publicar un precio, los arbitrajistas no pueden calcular uno, y la verificación del invariante que protege al pool de operaciones mal valoradas debe evaluarse de forma homomórfica en cada swap. Un mercado de préstamos tiene un problema más agudo: la liquidación requiere que terceros verifiquen que una posición está en negativo, lo que significa que o el factor de salud es público, anulando la confidencialidad, o los liquidadores deben solicitar el descifrado y actuar según el resultado, convirtiendo una transacción atómica en una secuencia de solicitud y callback de varios bloques, con un adversario libre de mover el colateral en el intermedio.

La asincronía es el obstáculo general. Cualquier composición que requiera un valor en texto plano a mitad de la ejecución no puede completarse dentro de una sola transacción, porque la vía de descifrado pasa por el Gateway y el comité de umbral. Los protocolos diseñados en torno a liquidación atómica dentro de un solo marco de llamada no se adaptan a esto mediante simple parametrización; requieren rediseño.

Esto deja una superficie de composabilidad a corto plazo centrada en aplicaciones donde la confidencialidad es el requisito primario y la tolerancia a la latencia es inherente: nóminas, donde quien paga conoce cada monto y terceros no fijan precio de los activos; liquidación institucional entre contrapartes que comparten información bilateralmente; y subastas de sobre cerrado, donde el mecanismo depende de que los valores permanezcan ocultos hasta una revelación programada, y donde esperar el descifrado por umbral al cierre es estructural. El marketing de Inco para su producto Lightning enumera un conjunto similar, incluyendo subastas ciegas, mercados monetarios, escrow de entrega contra pago, y vesting de tokens, reclamando soporte para ERC20 y SPL confidenciales “sin romper la composabilidad”. Esa afirmación requiere el mismo estándar de evaluación: no si la cadena base acepta el token, sino si un protocolo de terceros sin modificar puede fijar precio y liquidar contra él.

El techo de throughput y lo que excluye

El litepaper de Zama enmarca el escalamiento en tres etapas. El desempeño actual corre sobre procesadores de propósito general. Las GPU se describen como habilitadoras de un avance hacia “100+ transacciones/s”. Los aceleradores dedicados, FPGA y ASIC, se proyectan para alcanzar “miles de transacciones por segundo” en una fecha futura no especificada. Son objetivos prospectivos del proveedor sin una medición base publicada.

Las cifras específicas que circulan en torno a este lanzamiento, aproximadamente 20 transacciones por segundo hoy y un rango de 500 a 1.000 con GPU, no aparecen en el litepaper y no pudieron verificarse. La estimación más alta supera el lenguaje publicado por Zama sobre GPU por un factor de cinco a diez. Lo que implican las cifras del proveedor es que el hito de GPU coloca la ejecución confidencial en un throughput comparable al de una sola L2 de tamaño mediano haciendo trabajo en texto plano, compartido entre todas las aplicaciones de la capa.

Ese techo ordena claramente las cargas de trabajo de DeFi. Nóminas, vesting y liquidación institucional periódica generan cantidades de transacciones medidas en cientos o miles por día, donde una latencia de confirmación de segundos a minutos es operativamente manejable. Las subastas de sobre cerrado y la liquidación OTC operan como procesos por lotes. Ninguno de estos casos está limitado por throughput según la hoja de ruta publicada.

Los mercados continuos enfrentan restricciones distintas. El trading spot en AMM, las actualizaciones de tasa de financiación en perpetuos, las liquidaciones impulsadas por oráculos, y las estrategias de ejecución intrabloque requieren tanto throughput como latencia acotada, siendo la latencia la restricción vinculante. Incluso con mayores throughputs, un sistema en el que leer un valor requiere una ronda de descifrado por umbral no puede soportar liquidación competitiva. Si la confidencialidad basada en FHE sirve a esos mercados, lo hará ocultando campos específicos, como los tamaños de las órdenes o la composición del colateral, dentro de sistemas con formación de precios pública. Ese es un producto más acotado que el DeFi confidencial general.

También hay una dinámica de costos sin abordar. El gas onchain para la contabilidad de handles es bajo; la computación FHE ocurre en coprocesadores que requieren compensación. Cómo se mide ese costo, quién lo asume, y si el modelo de precios resiste picos de demanda son cuestiones económicas no establecidas en la documentación disponible. Un sistema cuyo costo computacional principal se sitúa fuera del mercado de comisiones de la capa de liquidación debe establecer un mercado de comisiones secundario donde se concentrará la congestión. La documentación de Fhenix ofrece una nota relevante: su entorno mock local simula FHE almacenando texto plano onchain, y la documentación indica que los costos de gas mock difieren de los de producción. Los benchmarks previos a mainnet de estos stacks deben evaluarse teniendo en cuenta esa brecha.

Quién sostiene las porciones de clave

El sistema de gestión de claves por umbral es el componente de esta arquitectura que más se asemeja a un supuesto de confianza convencional, y las fuentes disponibles ofrecen la especificación más escasa sobre él.

Zama afirma que el descifrado requiere que múltiples nodos independientes cooperen, impidiendo que una sola parte descifre unilateralmente los datos del usuario. La documentación no divulga el número total de nodos, el umbral de reconstrucción, la mecánica de selección y remoción de operadores, las jurisdicciones de los operadores, ni si la clave puede resegmentarse sin un paso de reconstrucción en texto plano. Cada una de estas variables afecta directamente la seguridad de los balances a nivel de sistema.

La comparación directa aclara las contrapartidas de confianza. En una L1 pública sencilla no hay paso de descifrado, así que no hay comité que comprometer o coaccionar; la contrapartida es la transparencia total. En un diseño de enclave de hardware, la confidencialidad depende del entorno de ejecución segura del fabricante del procesador y de la ausencia de vulnerabilidades de canal lateral, concentrando la confianza en la cadena de suministro de hardware. En un esquema de umbral, la confidencialidad se mantiene mientras menos del número umbral de operadores de nodos colude o es coaccionado, distribuyendo la confianza entre operadores sin eliminar por completo los supuestos de custodia.

Dos modos de falla requieren evaluación distinta. La confidencialidad falla si una coalición del tamaño del umbral reconstruye la clave, lo cual depende de la distribución jurisdiccional. La disponibilidad falla si el comité se niega a procesar solicitudes de descifrado. Un usuario cuyo balance permanece cifrado pero que no puede obtener un descifrado no puede probar la titularidad ni salir mediante contratos que requieren valores en texto plano. La censura en un sistema confidencial toma la forma de solicitudes de descifrado no atendidas más que de transacciones rechazadas.

El litepaper de Zama incluye una tabla comparativa que califica a su protocolo como simultáneamente seguro, descentralizado, verificable, componible, escalable y fácil de usar, mientras clasifica los enfoques basados en TEE como deficientes en seguridad y verificabilidad, y otros sistemas de FHE, MPC y ZK como deficientes en escalabilidad o usabilidad. Esa comparación representa el posicionamiento del proveedor. La contrapartida técnica subyacente sigue siendo concreta: la confianza en hardware y la confianza por umbral presentan modos de falla distintos.

Ajustar el mecanismo al adversario

El estado actual de las implementaciones sigue siendo dispar entre proveedores. El litepaper de Zama enumera la mainnet de Ethereum como objetivo para fines de 2025, con una explicación de ERC-7984 publicada en febrero de 2026 discutiendo casos de uso. La documentación de CoFHE de Fhenix especifica soporte para Ethereum Sepolia, Arbitrum Sepolia y Base Sepolia, con el soporte de mainnet en producción pendiente. Inco comercializa Lightning como una librería importable que ofrece velocidad nativa de la cadena sin una nueva VM, mientras reclama seguridad post-cuántica sin nombrar el mecanismo subyacente. Una latencia casi nativa es inconsistente con los perfiles estándar de sobrecosto de FHE, lo que lleva a suponer que se usan enclaves de hardware, aunque la documentación primaria no lo confirma.

Elegir un enfoque depende del modelo de amenaza y no de una lista de funciones. Donde una aplicación debe computar sobre datos que el usuario no puede retener, y donde una latencia del orden de segundos es aceptable, FHE con descifrado por umbral ofrece un fuerte aislamiento criptográfico dentro de límites de throughput bajo. Donde se requiere latencia nativa de la cadena base, la ejecución basada en enclaves es la alternativa activa, aceptando supuestos de confianza a nivel de hardware. Donde el objetivo es probar la ejecución válida sin que terceros computen el estado, las pruebas de conocimiento cero ofrecen una construcción de menor sobrecosto.

La nómina confidencial y la liquidación bilateral encajan con arquitecturas de FHE por umbral. La privacidad del flujo de órdenes en mercados continuos no encaja, ya que implementarla bajo las restricciones actuales introduce operadores confiables o latencia estructural.

Dónde puede romperse la tesis

Las preguntas abiertas principales son operativas más que criptográficas. Documentar la composición y gobernanza del comité de umbral establecerá si el descifrado depende de operadores repartidos en múltiples jurisdicciones legales o de un grupo concentrado. Benchmarks independientes en mainnet que midan la latencia desde el envío de la transacción hasta la obtención de un resultado legible aclararán el throughput práctico. Un informe de auditoría de la implementación ERC-7984 de OpenZeppelin confirmaría si la semántica de transferencia acotada y de control de acceso se sostiene bajo secuenciación adversarial.

Los factores económicos requieren igual escrutinio. La computación de coprocesadores representa el recurso escaso y se fija fuera del mercado base de liquidación. Hasta que se formalicen los mecanismos de comisiones, la dinámica de congestión permanece sin caracterizar. Una capa de confidencialidad donde la latencia de descifrado se dispara bajo carga corre el riesgo de dejar los balances de cuenta temporalmente ilegibles.

Las métricas de adopción deben evaluarse por integraciones de protocolo más que por volúmenes de transferencia aislados. Las transferencias confidenciales entre contrapartes conocidas demuestran la vía de ejecución básica del estándar más que una composabilidad general. El hito crítico a monitorear es que un protocolo de terceros sin modificar, como un mercado de préstamos o un AMM desarrollado sin integración con ERC-7984, fije precio y liquide contra un balance cifrado en producción. Hasta que se demuestre esa integración, los balances cifrados operan principalmente dentro de flujos de trabajo multipartitos acotados y no dentro de arquitecturas de DeFi abiertas.