Loading...
Este artículo es un espejo de Proof Street, una publicación independiente que cubre computación que preserva la privacidad: ZK, FHE, MPC, TEE e identidad descentralizada. Publicado originalmente como "Confidentiality compared: what four privacy architectures promise" el 12 de agosto de 2026. Reproducido con permiso del autor como parte de Zcash Community Grant #339. Por Stephen Webber.
A finales de julio, Zama activó un mercado de swaps confidenciales en Ethereum mainnet, en beta privada antes de un lanzamiento público en septiembre, que permite a un trader enviar una intención cifrada que oculta la cantidad, la tolerancia al deslizamiento y la dirección de la operación.
Para ello, se apoya en una pequeña coreografía. El trader deposita dos transferencias confidenciales, una con los activos reales y otra para la pierna opuesta con cantidad cero, de modo que un observador ve un movimiento bidireccional de tamaño oculto y no puede distinguir una compra de una venta. Los creadores de mercado autorizados descifran la intención, ven el tamaño pero no la dirección, y cotizan ambos lados. Una subasta de sobre cerrado se liquida on chain, y solo el creador ganador sabe en qué dirección se movió la operación. El resultado neto es un swap ejecutado con tamaño en una cadena pública, donde ninguna parte individual fuera de la operación llega a reunir el panorama completo.
Zama describe el producto como confidencial de extremo a extremo, pero ¿qué implica realmente esa confidencialidad? Aquí, la confidencialidad requiere confidencialidad a lo largo de toda una cadena de acciones, de modo que el público ve una cosa, los postores perdedores ven más, ya que descifraron el tamaño de la operación para poder cotizarla, y el postor ganador ve aún más. Dicho de forma simple, cada etapa de la secuencia es así por una decisión que alguien tomó sobre quién necesita saber qué, y cuándo. Sería agradable resumir la confidencialidad como "nadie ve nada", pero en la práctica nada funcionaría. La confidencialidad tiene que estar estructurada y tiene que seguir una secuencia.
Lo interesante es que casi diez años antes de ese lanzamiento, Zcash introdujo la primera capa de liquidación confidencial en una blockchain pública, usando pruebas de conocimiento cero para ocultar el remitente, el receptor y la cantidad de una transacción mientras demostraba a todos que la transacción era válida. En la década transcurrida desde entonces, "confidencial" se ha convertido en el adjetivo de al menos cuatro familias distintas de tecnología: transacciones blindadas, cifrado completamente homomórfico, computación multipartita y entornos de ejecución confiables. Productos de las cuatro familias ya funcionan en producción, varios de ellos en la misma cadena. Entonces, ¿qué hay dentro de la lata?
Las cuatro familias ofrecen respuestas diferentes y a veces superpuestas a cuatro problemas distintos, y dado que ahora cada respuesta llega empaquetada como un producto, la tarea real es averiguar qué problema tienes realmente.
Cualquier afirmación de confidencialidad, cuando la reduces a su mínima expresión, tiene que responder cuatro preguntas. ¿Qué datos están ocultos? ¿De quién? ¿Durante qué fase de la vida de los datos? ¿Y qué tiene que ser confiable para que la garantía sobreviva?
Como ejemplo, tomemos el mercado de swaps. Debe ocultar la cantidad, la dirección y el deslizamiento. ¿Por qué no el par de activos? Zama dice que una versión futura también lo ocultará. ¿De quién?: del público y de los bots de front-running por completo, de los creadores de mercado que cotizan de manera parcial, y del creador ganador en menor medida. ¿Durante qué fase?: durante la cotización y la subasta, con una divulgación diseñada en la liquidación. ¿Y en quién necesitas confiar?: la garantía descansa sobre la propia FHE, sobre los smart contracts y sobre un sistema de gestión de claves por umbral cuyos operadores no deben coludirse más allá de un umbral. Según el litepaper, ninguna parte individual puede acceder nunca a las claves de descifrado.
Es un diseño para ejecutar tamaño sin transmitir una estrategia. Los creadores de mercado ven el tamaño porque no pueden fijar el precio de una cotización sin él. El ganador conoce la dirección porque, bueno, la liquidación lo requiere.
Lo que muestra el ejemplo es que una afirmación que suena binaria, como si algo fuera confidencial o no, en realidad se descompone en un cronograma de exclusiones. Hay maneras muy diferentes de llegar a afirmaciones que suenan iguales.
Una transacción blindada de Zcash oculta el remitente, el receptor y la cantidad. Lo que permanece público es la prueba: un argumento de conocimiento cero, verificable por cualquiera que ejecute un nodo, de que la transacción oculta sigue las reglas. Los fondos blindados existen como notas cifradas, cada una un registro privado de una cantidad y su propietario que aparece on chain solo como un compromiso criptográfico. Gastar una nota publica un anulador, un valor que impide que la misma nota se gaste dos veces sin revelar de qué nota se trataba. Esto significa que la red puede rechazar dobles gastos sin llegar a saber nunca qué fondos se movieron, por lo que gastar no deja rastro que vincule una transacción con otra. El trabajo de la prueba es establecer que quien gasta era propietario de la nota, que los valores de la transacción cuadran y que no se creó ni destruyó ZEC, todo ello sin revelar ninguna de las cantidades implicadas.
La propiedad distintiva del diseño es más evidente al considerar en qué se debe confiar. No hay un comité que pueda descifrar una transacción blindada, ni un conjunto de operadores cuyo umbral de colusión importe, ni un fabricante de hardware cuya atestación deba creerse. Lo que queda en la base de confianza son las matemáticas y la corrección de los circuitos que codifican las reglas. Para cualquiera cuyo modelo de amenazas incluya la propia infraestructura, operadores sobre los que se pueda ejercer presión o fabricantes que puedan verse comprometidos, esa lista corta es el producto.
De hecho, esa base de confianza acaba de ser puesta a prueba en producción. El 29 de mayo, Taylor Hornby, un investigador de seguridad que auditaba para Shielded Labs, encontró una falla de solidez en el circuito de prueba del pool Orchard, presente desde el lanzamiento del pool en 2022, que, según la divulgación de Shielded Labs, podría haber permitido acuñar ZEC falsificados ilimitados dentro de Orchard sin dejar rastro on chain.
La corrección de emergencia se publicó en cinco días: Orchard se pausó el 2 de junio y luego fue restaurado el 3 de junio con un circuito corregido. La publicación sobre la remediación de ZODL describió el impacto de forma más acotada que Shielded Labs, al describir un riesgo de doble gasto dentro del pool en lugar de suministro falsificado, e informó que la privacidad de los usuarios y el límite total de suministro no se vieron afectados.
La reconstrucción de la verificabilidad llegó más tarde. Ironwood, activado como NU6.3 el 28 de julio, sella el pool Orchard de forma permanente, abre un pool nuevo sobre el circuito corregido, respaldado por auditorías independientes y trabajo de verificación formal, y enruta todos los fondos salientes a través de un torniquete que limita los retiros a lo que ingresó verificablemente, restaurando la capacidad de cada usuario de verificar de forma independiente el suministro circulante sin ver las transacciones de nadie. El episodio es el libro mayor de la base de confianza en acción. Cuando falló la corrección del circuito, el remedio fue matemáticas y migración, no la discreción de un comité, y el radio de impacto estuvo limitado por la auditabilidad que la arquitectura había incorporado en el límite del pool años antes.
Lo que el blindaje compra con esa base de confianza mínima es deliberadamente estrecho. El estado oculto es un pago, valor que se mueve de una parte a otra. No hay un estado cifrado compartido sobre el que muchas partes computen, ni lógica de contrato confidencial, ni libro de órdenes cifrado.
FHE permite ejecutar cómputo sobre texto cifrado. En el protocolo de Zama, la versión ya activa en Ethereum, los saldos y las cantidades de transferencia existen on chain como identificadores cifrados bajo el borrador del estándar ERC-7984, coprocesadores realizan la aritmética cifrada off chain, y el descifrado requiere un cuórum de operadores independientes de gestión de claves, trece organizaciones en el lanzamiento de mainnet, seleccionadas por reputación y por su involucramiento operativo, de modo que ninguna parte individual pueda leer los datos. Esto es lo que hace posible un libro de órdenes cifrado o un pool de préstamos confidencial: el estado oculto de muchas partes, componiéndose dentro de una lógica de contrato compartida.
Pero ¿qué pasa con el comité de gestión de claves? Alguien tiene que poder descifrar, o los datos no son utilizables. La respuesta del diseño es hacer que ese alguien sea un umbral de operadores independientes en lugar de un custodio único, y gobernar quién puede descifrar qué valores mediante control de acceso escrito en los propios contratos, extensible a partes designadas como auditores, un mecanismo de delegación cuyas implicaciones de cumplimiento pertenecen a la siguiente parte de esta serie. La pregunta para alguien que evalúa soluciones es si la composición del comité, sus incentivos y su umbral coinciden con el modelo de amenazas del evaluador.
La computación multipartita divide los datos en participaciones distribuidas entre nodos independientes, que conjuntamente calculan un resultado sin que ningún nodo reconstruya las entradas. Avishay Yanai, cofundador y CEO de Soda Labs, cuya máquina virtual de circuitos ofuscados ejecuta en producción lógica de contratos compatible con EVM sobre valores cifrados en la red COTI, describe un buen diseño de MPC en producción como aquel que garantiza que ninguna parte individual, ya sea un observador, un nodo que ejecuta el cálculo o el proveedor, vea nunca entradas en texto plano ni estado intermedio, y que todos vean solo lo que la política de divulgación les permite. La garantía depende únicamente de la no colusión, y esa es una suposición sobre la que se puede diseñar y contratar, por ejemplo con operadores en jurisdicciones separadas, en nubes separadas y bajo auditorías independientes, con exposición legal por colusión. El trabajo de la criptografía aquí es lo que él llama una enorme reducción de confianza en lugar de una eliminación de la confianza, para alcanzar equivalencia con la confianza que las instituciones depositan en las cámaras de compensación. La colusión por encima del umbral rompe la privacidad, pero no la corrección, ya que en diseños con auditabilidad pública, validadores externos aún pueden comprobar que los resultados reportados son correctos sin unirse al cálculo.
La salvedad es simplemente que tal observador ve que ocurrió una transacción, cuándo, contra qué contrato, quién la envió, además de tamaños de lote y comisiones. Un nodo participante puede saber qué función se ejecutó y sus patrones de rendimiento. La correlación temporal es otra consideración, ya que los niveles de actividad pueden filtrarse incluso cuando las cantidades no lo hacen. Y cualquier cosa que la aplicación emita en texto plano, pequeñas divulgaciones repetidas podrían crecer hasta convertirse en patrones potenciales para una parte que los esté buscando. "Es el límite de la promesa", aclara, por lo que quienes evalúan deberían exigir a los proveedores que lo delimiten explícitamente. Ningún modelo de cómputo corrige el envío de texto plano por parte de, por ejemplo, un cliente comprometido. El protocolo computa fielmente sobre cualquier cosa que se le dé. Quién habla con quién es un problema de transporte, y el cumplimiento es una política más que un mecanismo: "Ninguna criptografía hace ese juicio por ti".
Los diseños de circuitos ofuscados se ejecutan en rondas constantes con el pesado material criptográfico precalculado antes de que existan las entradas, lo que hace factibles cargas de trabajo a ritmo de transacción allí donde los protocolos de compartición secreta pagan viajes de ida y vuelta de red por operación, y donde, según Yanai, algunas familias de MPC protegen los valores pero no el hecho del cómputo, los diseños de circuitos ofuscados pueden extender cobertura a las direcciones de contraparte y a los tipos de activos. Sin embargo, la propiedad más importante de esta familia para esta comparación es que MPC es una arquitectura por derecho propio y también es un ingrediente dentro de las otras familias: el comité de claves por umbral bajo un despliegue FHE es en sí mismo una computación multipartita. La pregunta del evaluador, en el marco de Yanai, es "¿qué hace mi comité y qué pago por encima de eso?" Si el comité existe de todos modos, ejecutar el propio cómputo en MPC puede eliminar una capa externa costosa.
Vale la pena aclarar que se discuten dos productos muy diferentes usando el mismo acrónimo. El MPC de custodia divide una clave de firma entre varias partes para que ninguna de ellas pueda firmar por sí sola; protege un secreto, y el cálculo conjunto implicado es una sola operación fija, producir una firma. El MPC de cómputo ejecuta lógica general de programas sobre datos que permanecen ocultos en todo momento, e involucra entradas de muchas partes, lógica arbitraria de contratos y operación continua. Las matemáticas son lo que ambos tienen en común. Operativamente, sin embargo, uno se usa para gestión de claves y el otro es un entorno de ejecución confidencial.
Un TEE es una región de un procesador aislada por hardware que mantiene los datos cifrados en memoria y protegidos del sistema operativo, del hipervisor y del operador de la máquina, con atestación remota que permite a una parte externa verificar qué código se está ejecutando dentro. El diseño compra las dos cosas por las que las familias criptográficas pagan caro, generalidad y velocidad: un enclave ejecuta programas ordinarios a un costo cercano al ordinario, razón por la cual los TEE sostienen la mayoría de las ofertas de cómputo confidencial de las grandes nubes y un conjunto creciente de infraestructura de cadena.
La base de confianza es el intercambio, porque la garantía solo es tan fuerte como el diseño y la cadena de suministro del fabricante de hardware, la infraestructura de atestación y la resistencia del enclave a la extracción por canal lateral, una clase de ataque con una larga historia publicada. Los diseñadores de TEE conocen este libro mayor mejor que sus críticos. Elegir la arquitectura significa hacer una apuesta deliberada a que la confianza en el hardware más la atestación es el precio correcto para ejecutar cargas de trabajo reales a velocidad real, y para muchos despliegues lo es.
¿Podría Zcash blindado servir para el caso de uso de un mercado de trading confidencial? No, pero eso no es una carencia. Un mercado de RFQ es estado cifrado compartido bajo lógica de contrato, las intenciones ocultas de muchas partes componiéndose dentro de una subasta que en sí misma opera a ciegas. Eso es más apropiado para algo como MPC, con estado privado compartido bajo interacción frecuente, un libro de órdenes, un ciclo de compensación. El blindaje no tiene un sustrato para eso; su estado oculto es un pago entre dos partes. El propio mercado es adecuado para FHE o MPC, y vale la pena notar que cuando Zama lo construyó, la confidencialidad que ofrece es un cronograma de divulgaciones a creadores de mercado autorizados e identificados, lo cual es necesario para el trading institucional. Pero ese es un producto distinto de lo que ofrece una transacción blindada, que es confidencialidad sin lista blanca y sin ninguna parte que eventualmente conozca tu dirección.
¿Y qué hay de los pagos corporativos y las nóminas? Este es un mercado que ahora cortejan todos los proveedores de FHE y MPC, y es exactamente el problema para el que se construyó el blindaje: cantidades ocultas, contrapartes ocultas, validez pública. En principio, una cadena blindada es la respuesta de base de confianza más fuerte disponible, sin comité, sin proveedor, sin conjunto de operadores. En la práctica, el mercado de pagos corporativos se está ganando con rails, integración ERC-20, custodios existentes, herramientas de cumplimiento existentes, denominaciones en stablecoins, y Zcash blindado ofrece un activo distinto en una cadena distinta. Pero encaja bien a nivel de la forma del problema y simplemente está esperando integración. La criptografía puede hacerlo, así que las preocupaciones prácticas tienen que ver con con qué se conecta el stack circundante.
También vale la pena observar lo que ofrecen las otras tres familias, y el blindaje no: una parte a la que se puede obligar. Un comité por umbral puede recibir una orden judicial, un proveedor de enclaves puede ser citado para entregar sus claves de firma, y un conjunto de operadores tiene una jurisdicción. Una institución que necesita una vía de cumplimiento puede considerar que el comité es el producto. También es, visto desde otro asiento, la vulnerabilidad.
Si volvemos a mirar los casos examinados arriba, vemos una imagen superpuesta. La mayoría de los despliegues de FHE tienen MPC por umbral debajo como capa de descifrado. Las pruebas de conocimiento cero certifican entradas cifradas antes de que FHE las consuma y, en sistemas de circuitos ofuscados, pueden certificarlas a posteriori, dando a los usuarios una salida forzada que no depende de la disponibilidad de la red, una práctica tomada de las arquitecturas rollup. Los TEE aparecen dentro de nodos MPC como defensa en profundidad, los nodos de gestión de claves de Zama ejecutan su parte del cálculo dentro de enclaves de hardware, y los TEE alojan cada vez más a los probadores y constructores de sistemas cuyas garantías finales son criptográficas. Una comparación escrita dentro de cinco años podría encontrar difícil localizar las costuras. Pero la composición solo avanza en una dirección.
Por eso, la forma duradera de la pregunta del evaluador no trata en absoluto de "qué tecnología". Lo que hay que buscar es cómo se secuencia la confidencialidad, qué se excluye y qué hace cumplir la exclusión, ya sean las matemáticas y la corrección del circuito, la no colusión de un comité, un umbral de nodos honestos o el silicio de un proveedor. Lee cualquier afirmación de confidencialidad preguntando qué está oculto, de quién, hasta cuándo y bajo la palabra de quién, y entonces lo sabrás.
Divulgación: este texto fue respaldado por una Zcash Community Grant. ZCG no revisó ni aprobó este texto antes de su publicación. Los compromisos de financiación de Proof Street figuran en la página de financiación.
Páginas relacionadas: Shielded Pools (Using_Zcash) · Viewing Keys · la página "quién puede ver qué" en Start_Here — sustituir por rutas exactas del wiki