Construyendo una piscina oscura en Stellar: Comparación de MPC, FHE y TEEs

Cuando un inversor institucional quiere comprar medio millón de acciones en una bolsa tradicional, enfrenta un dilema: colocar la orden públicamente y ver cómo el precio se mueve en su contra a medida que el mercado anticipa su movimiento. Por esto existen los dark pools en las finanzas tradicionales—lugares privados donde grandes órdenes se ejecutan sin revelar las intenciones al mercado más amplio.

En muchas blockchains, las transacciones pendientes se propagan a través de redes de chismes observables públicamente (y en cadenas EVM, un mempool público), dando a los bots visibilidad anticipada para adelantarse. El flujo en Stellar es diferente y las confirmaciones son rápidas, pero el punto más amplio permanece: cuando las órdenes o intenciones son visibles antes de la ejecución, los actores sofisticados pueden explotar esa información.

Nos propusimos explorar cómo podría funcionar el comercio que preserva la privacidad en Stellar. El viaje nos llevó a través de pruebas de conocimiento cero, computación multipartita, cifrado completamente homomórfico y entornos de ejecución confiables. Esto es lo que aprendimos.

Adversarios: Operadores de intercambio que podrían adelantarse, bots MEV monitoreando el flujo de órdenes, proveedores de nube que alojan infraestructura.

Las suposiciones de confianza varían según el enfoque: Proveedor de hardware (TEEs), cuórum honesto (MPC), consenso de cadena (liquidación en cadena).

Objetivos: Privacidad pre-comercio (ocultar órdenes antes de la ejecución), privacidad post-comercio (opcional), resistencia a la censura, vitalidad.

Un Libro de Órdenes Centralizado (CLOB) está en el corazón de la mayoría de los intercambios. Las órdenes de compra y venta se ordenan por precio—las ofertas de mayor a menor, las demandas de menor a mayor. Los mejores precios se emparejan primero, y cuando dos órdenes comparten un precio, la primera tiene prioridad.

Existen diferentes mecanismos de emparejamiento. Las Subastas Dobles Continuas (CDA), utilizadas en la mayoría de los mercados modernos, permiten a compradores y vendedores enviar órdenes en cualquier momento durante el comercio, con operaciones que se ejecutan inmediatamente al coincidir. Las subastas periódicas, o Comercio de Volumen, funcionan de manera diferente: hay una fase abierta donde se envían las órdenes, luego una fase de descubrimiento de precios calcula el precio que maximiza el volumen comercializado, y todas las operaciones se ejecutan a ese precio uniforme.

Con una implementación de libro de órdenes estándar, las órdenes no emparejadas son visibles para el operador (y en DeFi, para todos). Esta visibilidad habilita dos formas particularmente desagradables de explotación:

Adelantamiento ocurre cuando alguien ve tu gran orden de compra pendiente en el mempool y rápidamente coloca su propia orden de compra primero. El precio sube, y terminas pagando más. Ellos se benefician del movimiento de precio que tu orden causó.

Ataques de sándwich llevan esto más allá. El atacante coloca una orden de compra antes de la tuya (adelantamiento), luego una orden de venta después de la tuya (posterior). Tu transacción queda "sándwich" entre las de ellos. Compran barato, tu orden sube el precio, y venden caro—capturando el movimiento de precio que ellos ingenieraron a tu costa.

Estas no son preocupaciones teóricas. Los bots MEV (Valor Máximo Extraíble) extraen un valor sustancial de los usuarios DeFi a través de exactamente estas técnicas.

Las pruebas de conocimiento cero son herramientas poderosas para la verificabilidad. Permiten que una parte fuera de la cadena ejecute un programa y pruebe en cadena que el resultado se calculó correctamente, sin revelar las entradas privadas del programa.

A primera vista, esto parece ideal para un dark pool: lugares de comercio privado fuera de la bolsa. Un operador podría emparejar órdenes fuera de la cadena, publicar el resultado y proporcionar una prueba ZK de que el algoritmo de emparejamiento se ejecutó correctamente.

El problema es que las pruebas ZK por sí solas no proporcionan confidencialidad pre-ejecución en un modelo impulsado por el operador. A menos que las órdenes estén cifradas u ocultas de alguna otra manera del operador hasta que se complete la ejecución, el operador necesariamente aprende el flujo de órdenes mientras ensambla la prueba. Esto reintroduce la misma asimetría de información que los dark pools intentan eliminar.

Uno podría intentar abordar esto con un protocolo de subasta de compromiso-revelación o de dos fases: los comerciantes primero envían compromisos criptográficos de sus órdenes, el operador se compromete con un lote, y solo entonces se revelan las órdenes para el emparejamiento. Esto ayuda a prevenir el adelantamiento directo dentro de una ronda, pero no resuelve completamente el problema. El operador aún aprende órdenes no emparejadas, revelando la intención a corto plazo de los comerciantes. Incluso si la explotación no puede ocurrir inmediatamente, esta información puede usarse estratégicamente en rondas subsiguientes.

En resumen, las pruebas ZK son excelentes para asegurar la corrección, pero sin un mecanismo de confidencialidad adicional—como MPC, FHE, o TEEs—no impiden que las partes privilegiadas aprendan el flujo de órdenes y actúen en base a ello. Para un verdadero dark pool, ocultar las entradas antes y durante la ejecución es tan importante como probar que el resultado fue correcto.

Antes de construir nuestra propia solución, examinamos enfoques existentes:

Penumbra [3] reduce el MEV basado en ordenación agrupando intenciones y ejecutando intercambios como un lote al final de cada bloque; el ordenamiento de transacciones dentro del bloque se vuelve menos relevante. Sin embargo, el operador todavía puede potencialmente afectar los precios de liquidación introduciendo sus propias posiciones, y la visibilidad parcial de la intención sigue siendo una consideración.

Unyfy [4] combina enclaves seguros con pruebas ZK. Los compromisos con las órdenes se publican en cadena, pero el emparejamiento ocurre dentro de TEEs. Las pruebas ZK verifican la ejecución correcta independientemente de la confianza en el hardware. Es un híbrido interesante: blockchain para la custodia, TEEs para la confidencialidad, ZK para la verificabilidad.

Sunscreen utiliza FHE umbral, similar a lo que exploramos en nuestros propios experimentos.

• ZK: Verificable, pero no inherentemente confidencial en un modelo de operador. La vitalidad depende de la disponibilidad del demostrador.
• MPC: Confidencial (con umbral honesto). La verificabilidad depende del diseño del esquema/comité. La vitalidad requiere participación del cuórum.
• FHE: Confidencial. La verificabilidad es separada (necesita ZK o redundancia). Demasiado lento para esta carga de trabajo hoy.
• TEE: Confidencial con suposiciones de confianza en el hardware. La integridad atestiguada proporciona verificabilidad. La vitalidad/resistencia a la censura depende del operador.

Punto dulce híbrido: TEE para velocidad + ZK para verificabilidad pública de invariantes críticos (p.ej., solvencia, corrección del emparejamiento). Unyfy ejemplifica este enfoque.

MPC permite el cálculo privado distribuido a través de múltiples partes. Varios protocolos ofrecen diferentes garantías—algunos requieren una mayoría honesta, mientras que el protocolo SPDZ [6] garantiza privacidad a menos que todas las partes coluden.

Para un dark pool, MPC significa que múltiples partes no coludidas ejecutan el emparejamiento de órdenes colectivamente sin que ninguna parte única vea las órdenes entrantes antes de que se revelen los resultados. Esto previene genuinamente el adelantamiento y los ataques de sándwich. Cartlidge et al. demostraron este enfoque usando el marco SCALE-MAMBA en su papel "MPC Se Une al Lado Oscuro” [1].

Construimos un prototipo en Stellar usando el marco MP-SPDZ [2], implementando un protocolo de emparejamiento para subastas periódicas. MP-SPDZ ofrece un modelo de programación similar a Python que se compila a protocolos MPC, haciéndolo más accesible que SCALE-MAMBA (aunque este último tiene soporte experimental de Rust a través de la compilación WASM).

Entendiendo la estructura de dos fases de SPDZ:

SPDZ divide el cálculo en una fase offline (preprocesamiento) y una fase online. La fase offline genera "tríos de Beaver"—valores aleatorios correlacionados que habilitan la multiplicación segura. Estos tríos son la parte costosa de producir, pero una vez que los tienes, la fase online es notablemente rápida.

El problema: cada trío de Beaver solo puede usarse una vez. Más cálculo significa más tríos necesarios. Y para un intercambio 24/7 con volumen impredecible, el preprocesamiento continuo ayuda pero no elimina la restricción fundamental—todavía necesitas generar tríos al menos tan rápido como los consumes, y los picos en la actividad comercial pueden superar la capacidad de preprocesamiento.

Nuestros resultados experimentales:

Simulamos 50 compradores y 50 vendedores por ronda, midiendo el tiempo de cálculo combinado offline+online en un Apple M3 MacBook Air. Los resultados mostraron una clara escalabilidad lineal:

La relación lineal con las rondas tiene sentido: cada ronda requiere tríos de Beaver frescos que solo pueden usarse una vez. Un estudio más exhaustivo desacoplaría las fases offline y online para medirlas independientemente.

La escalabilidad de los participantes es más preocupante:

También medimos cómo el tiempo aumenta con el número de participantes por ronda. Aquí también vemos un crecimiento aproximadamente lineal: alrededor de 100 segundos para 100 participantes, subiendo a unos 600 segundos para 1,200 participantes.

Para un intercambio con miles de participantes y altos volúmenes de comercio, esta escalabilidad lineal se convierte en una seria limitación que el preprocesamiento por sí solo no puede resolver.

Una nota sobre la verificación MPC:

No es suficiente compartir secretamente las entradas y ejecutar el emparejamiento a través de MPC: también necesitamos verificar que los resultados afirmados realmente provienen de la ejecución correcta del protocolo por un umbral de participantes honestos. Los participantes de MPC mantienen un estado secreto durante todo el proceso y se ejecutan fuera de la cadena, pero los resultados de la subasta deben comprometerse en la cadena. Un patrón común es la atestación del comité: un umbral de nodos MPC firma conjuntamente la salida. La verificación pública no interactiva como un SNARK sobre la ejecución de MPC es posible, pero típicamente añade complejidad y costo.

FHE es criptográficamente hermoso: computa sobre datos encriptados sin nunca desencriptarlos. Los comerciantes podrían enviar órdenes encriptadas bajo una clave pública correspondiente al esquema FHE. El operador evaluaría el algoritmo de emparejamiento sobre los cifrados, produciendo un resultado encriptado. La clave de desencriptación correspondiente podría ser compartida secretamente entre múltiples operadores, permitiendo a un quórum desencriptar los resultados sin que ninguna parte vea las órdenes en texto plano.

FHE por sí solo no garantiza la correcta ejecución del algoritmo, pero eso es solucionable. El verdadero problema es el rendimiento.

Usando la biblioteca Concrete FHE de Zama, simulamos solo 10 compradores y 10 vendedores con volúmenes aleatorios y diferentes límites.

Tiempo de computación: 204 minutos. Más de tres horas para 20 participantes.

(Detalles del benchmark: nivel de seguridad, precisión y parámetros están documentados en el repo; los resultados son ilustrativos, no una constante universal.)

Esto no es una crítica a la implementación de Zama, es un excelente trabajo avanzando FHE. Pero para el comercio de alto rendimiento con muchos participantes, FHE simplemente no es viable con la tecnología actual. La brecha entre lo que es teóricamente posible y lo que es prácticamente usable sigue siendo enorme. Compara esto con los ~30 segundos que MPC tarda para 100 participantes: FHE es órdenes de magnitud más lento. Esto no es meramente un desafío de ingeniería que simplemente toma tiempo. Se requiere un avance significativo para que FHE se convierta en una solución adecuada, ya sea una innovación teórica en forma de una construcción criptográfica más eficiente, o soluciones de aceleración de hardware que de alguna manera mejoren el rendimiento por órdenes de magnitud.

Los Entornos de Ejecución Confiables (TEEs), incluyendo Intel SGX y TDX, AMD SEV-SNP, y AWS Nitro Enclaves, proporcionan computación aislada por hardware con atestación remota. El código y los datos solo se desencriptan dentro del contexto de ejecución protegido, mientras que el entorno circundante, incluyendo el SO y el hipervisor, se trata como no confiable.

Para un dark pool, esto se ajusta limpiamente al problema. Los comerciantes pueden enviar órdenes encriptadas a un motor de emparejamiento atestado, confiando en que los datos de las órdenes en texto plano solo son visibles dentro del TEE. La lógica de emparejamiento se ejecuta en hardware nativo, y los resultados se devuelven junto con la prueba criptográfica de que un enclave genuino ejecutando una base de código específica y auditada los produjo.

Los TEEs combinan efectivamente las fortalezas de otros enfoques: confidencialidad comparable a FHE, garantías de integridad similares en espíritu a las pruebas ZK, y rendimiento cercano a la ejecución nativa. No hay necesidad de dividir la computación entre muchas partes u operar sobre datos encriptados; los motores de emparejamiento existentes a menudo pueden desplegarse con mínimas modificaciones.

El compromiso es la confianza en la plataforma de hardware y su infraestructura de atestación. Los TEEs no eliminan todos los riesgos: los ataques de canal lateral siguen siendo un área activa de investigación, y los TEEs no proporcionan inherentemente resistencia a la censura o garantías de disponibilidad. Un operador malicioso o no disponible aún puede negar el servicio o desconectarse.

Sin embargo, cuando se combinan con liquidación en cadena, atestación transparente y técnicas de defensa en profundidad (como pruebas ZK para invariantes críticos), los TEEs ofrecen el camino más práctico hacia el comercio privado de grado de producción hoy en día. Para sistemas que requieren tanto un alto rendimiento como una fuerte confidencialidad previa al comercio, actualmente representan el mejor compromiso de ingeniería disponible.

Construimos un prototipo funcional en Stellar usando Phala's TEE Cloud, que ofrece VMs confidenciales habilitadas para Intel TDX. El código está disponible en GitHub, y aunque es experimental, demuestra el flujo completo desde la presentación de la orden hasta la liquidación en cadena.

El sistema tiene dos componentes trabajando en conjunto. Fuera de la cadena, un motor de emparejamiento Python se ejecuta dentro del TEE, recibiendo órdenes firmadas a través de API REST y manteniendo un libro de órdenes privado con emparejamiento por prioridad de precio-tiempo. En la cadena, un contrato inteligente de Stellar gestiona los saldos de las bóvedas de los usuarios y ejecuta transferencias atómicas cuando se liquidan los comercios.

El modelo de bóveda es clave para habilitar la liquidación instantánea. Los comerciantes depositan fondos en el contrato con antelación. Cuando el motor de emparejamiento encuentra una coincidencia, llama a la función de liquidación del contrato, que actualiza los saldos de la bóveda de forma atómica. No se necesitan firmas de usuarios en el momento de la liquidación ya que los fondos ya están bloqueados, pero las órdenes mismas son firmadas por los comerciantes usando SEP-0053. El contrato de liquidación verifica que los comercios presentados hagan referencia a órdenes firmadas válidas, verifica los ID de las órdenes para la protección contra la repetición y confirma que el motor de emparejamiento está autorizado. Esto evita que el motor liquide a precios o cantidades no autorizadas.

Estableciendo Confianza Sin una Autoridad de Certificación

Aquí es donde las cosas se ponen interesantes. El motor de emparejamiento utiliza un certificado TLS autofirmado, lo cual normalmente sería una señal de alerta. Pero la clave privada de ese certificado fue generada dentro del TEE y nunca ha existido en ningún otro lugar. Lo mismo es cierto para la clave de firma de Stellar que el motor utiliza para autorizar liquidaciones.

Para probar esto, vinculamos ambas claves públicas en la atestación de Intel TDX. El TEE calcula un hash combinando la clave pública de Stellar, el hash SPKI del certificado TLS (una huella dactilar criptográfica), un sello de tiempo y un desafío opcional proporcionado por el cliente. Este hash va al campo reportData de la cita de atestación, que luego firma el hardware de Intel.

La configuración de Docker Compose, incluyendo un digesto de imagen de contenedor fijado, también se hashea y registra en la atestación. Cualquiera puede obtener esta configuración, calcular el hash por sí mismo y verificar que coincide con lo que Intel atestiguó. Esto prueba que el motor de emparejamiento está ejecutando exactamente el código que fue auditado, no alguna versión modificada.

Cuando un cliente se conecta, pueden extraer el certificado TLS de la conexión en vivo, calcular su hash SPKI y verificar que coincide con lo que está en la cita de atestación. Si coincide, saben que su conexión encriptada termina dentro del TEE genuino, no en algún proxy intermediario.

Cómo Sucede Realmente un Comercio

Un comerciante comienza depositando tokens en la bóveda del contrato de liquidación. Luego firman una orden usando SEP-0053 (el estándar para la firma de mensajes fuera de la cadena en Stellar) y la envían al motor de emparejamiento a través de HTTPS.

El motor de emparejamiento valida la firma y añade la orden a su libro. Cuando llega una orden coincidente, el motor construye una transacción de Stellar llamando a la función de liquidación del contrato. El contrato verifica que el llamador es el motor de emparejamiento autorizado, luego intercambia los saldos de la bóveda de forma atómica: el comprador recibe el activo base, el vendedor recibe el activo de cotización.

Todo esto sucede con los detalles de la orden ocultos hasta el momento de la liquidación. El operador de infraestructura que ejecuta Phala Cloud puede ver el tráfico de red encriptado entrando y saliendo, pero la encriptación de memoria del TEE significa que no pueden ver el libro de órdenes o la lógica de emparejamiento ejecutándose.

Lo Que Esto Demuestra (Y Lo Que No)

La atestación nos da autenticidad del hardware (la cita está firmada por silicio genuino de Intel TDX), integridad del código (el hash de compose prueba exactamente lo que está ejecutando) y confinamiento de claves (las claves TLS y Stellar provienen de manera probada de esta instancia de TEE).

Lo que no nos da es certeza absoluta sobre la privacidad de la memoria durante la ejecución: los ataques de canal lateral son un riesgo práctico de investigación en curso para todas las implementaciones de TEE, con nuevas vulnerabilidades y parches emergiendo regularmente. La defensa en profundidad (combinando TEEs con otros mecanismos como la verificación de liquidación en cadena) ayuda a mitigar esto. Tampoco proporciona resistencia a la censura (el operador podría negarse a incluir ciertas órdenes) o garantías de disponibilidad (el TEE simplemente podría desconectarse, aunque los depositantes aún podrían retirar sus fondos del contrato en cadena).

Brechas Restantes

Quedan dos piezas significativas antes de que esto pueda estar listo para producción.

Primero, verificación de atestación a nivel de contrato. Actualmente, los clientes verifican la confianza al obtener la clave pública del motor de emparejamiento registrado del contrato de liquidación, luego comparándola con lo que aparece en la cita de atestación del motor de emparejamiento (o viceversa: obtener la atestación primero, luego confirmar que el contrato ha registrado esa misma clave). Esto funciona y puede ser completamente automatizado, pero la verificación de confianza ocurre del lado del cliente. Un diseño más fuerte tendría el contrato de liquidación verificando de forma independiente las citas de atestación, previniendo que un motor de emparejamiento comprometido sea intercambiado incluso si los clientes omiten la verificación.

Segundo, verificación del kernel del SO. Necesitamos verificar el hash del kernel del SO de Phala contra una construcción reproducible. Phala ejecuta Dstack [5], que es de código abierto con construcciones reproducibles. La herramienta existe, solo necesitamos completar la tubería de verificación para asegurar que toda la pila de software, no solo nuestro contenedor, coincida con los valores esperados.

Si estás desarrollando infraestructura de comercio que preserva la privacidad, aquí está nuestra evaluación:

FHE: No viable para comercio de alto rendimiento. La tecnología avanza rápidamente, pero el rendimiento actual es órdenes de magnitud demasiado lento para uso práctico.

MPC: Viable para sistemas de participación limitada o intercambios con ventanas naturales de comercio. La escalabilidad lineal con los participantes es una restricción dura, pero si tienes un conjunto pequeño y conocido de participantes, funciona bien y proporciona garantías criptográficas fuertes sin suposiciones de confianza en el hardware.

TEEs: La opción pragmática para sistemas de producción hoy en día. Rendimiento nativo, implementación lift-and-shift y fuertes garantías de privacidad hacen esta la mejor opción para la mayoría de los casos de uso. El compromiso es confiar en la plataforma de hardware, pero combinar TEEs con liquidación en cadena y pruebas ZK (como hace Unyfy) puede proporcionar defensa en profundidad.

El comercio que preserva la privacidad está pasando de la investigación a la producción. Lo estamos viendo en proyectos como Renegade [7], Penumbra y Unyfy. Las herramientas están madurando. La demanda, de inversores institucionales que no pueden permitirse ser adelantados en sus posiciones, es muy real.

Para Stellar específicamente, la combinación de finalidad rápida, bajos costos de transacción y la plataforma de contratos inteligentes Soroban la hacen bien adecuada para este tipo de infraestructura. Nuestro prototipo demuestra que la arquitectura central funciona.

El trabajo restante es de ingeniería, no de investigación: fortalecer la verificación de atestiguamiento (incluyendo la verificación de cotizaciones a nivel de contrato), completar la verificación del kernel del SO contra construcciones reproducibles y pruebas de estrés a escala. Los fundamentos criptográficos son sólidos.

El código para nuestro prototipo MPC está disponible en dark-pool-mpc, los experimentos FHE en dark-pool-fhe, y el prototipo basado en TEE en stellar-dark-pool.