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 lo anticipa. Por esto existen los dark pools en las finanzas tradicionales: lugares privados donde se ejecutan grandes órdenes sin revelar las intenciones al mercado más amplio.

En muchas blockchains, las transacciones pendientes se propagan a través de redes de chismes públicamente observables (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, encriptación homomórfica completa y entornos de ejecución de confianza. 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), quó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, vivacidad.

Un Libro de Órdenes Central Limitado (CLOB) se encuentra en el corazón de la mayoría de los intercambios. Las órdenes de compra y venta se clasifican 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 la negociación, 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 negociado, y todas las operaciones se ejecutan a ese precio uniforme.

Con una implementación estándar del libro de órdenes, las órdenes no emparejadas son visibles para el operador (y en DeFi, para todos). Esta visibilidad permite 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 sandwich 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 (retraso). Tu transacción queda "sandwichada" 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 de MEV (Valor Máximo Extraíble) extraen un valor sustancial de los usuarios de DeFi a través de exactamente estas técnicas.

Las pruebas de conocimiento cero son herramientas poderosas para la verificabilidad. Permiten a una parte fuera de la cadena ejecutar un programa y probar 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 privados 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 encriptadas o de otra manera ocultas al 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 de inmediato, esta información puede usarse estratégicamente en rondas posteriores.

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 consecuencia. 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, observamos enfoques existentes:

Penumbra [3] reduce el MEV basado en ordenamiento 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 aún 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 los TEEs. Las pruebas ZK verifican la ejecución correcta independientemente de la confianza en el hardware. Es un híbrido interesante: blockchain para custodia, TEEs para confidencialidad, ZK para verificabilidad.

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

• ZK: Verificable, pero no inherentemente confidencial en un modelo operador. La vivacidad depende de la disponibilidad del demostrador.
• MPC: Confidencial (con umbral honesto). La verificabilidad depende del diseño del esquema/comité. La vivacidad requiere participación de quó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 hardware. La integridad atestiguada proporciona verificabilidad. La vivacidad/resistencia a la censura depende del operador.

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

MPC permite el cálculo privado distribuido entre 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 sandwich. 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 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 fuera de línea (preprocesamiento) y una fase en línea. La fase fuera de línea genera "triples de Beaver"—valores aleatorios correlacionados que permiten la multiplicación segura. Estos triples son la parte costosa de producir, pero una vez que los tienes, la fase en línea es notablemente rápida.

La trampa: cada triple de Beaver solo se puede usar una vez. Más cálculo significa más triples necesarios. Y para un intercambio 24/7 con volumen impredecible, el preprocesamiento continuo ayuda pero no elimina la restricción fundamental: aún necesitas generar triples 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ómputo 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 nuevos triples de Beaver que solo pueden usarse una vez. Un estudio más detallado desacoplaría las fases offline y online para medirlas de manera independiente.

La escalabilidad de los participantes es más preocupante:

También medimos cómo aumenta el tiempo con el conteo de participantes para una sola ronda. Aquí también vemos un crecimiento lineal aproximado: 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 solo no puede resolver.

Una nota sobre la verificación MPC:

No es suficiente compartir secretos de 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 operan fuera de la cadena, pero los resultados de las subastas deben comprometerse en la cadena. Un patrón común es la atestación del comité: un umbral de nodos MPC firman conjuntamente el resultado. 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 en secreto entre múltiples operadores, permitiendo un quórum para 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 cálculo: 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 impulsando FHE hacia adelante. 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. Compárese 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 de Confianza (TEEs), incluyendo Intel SGX y TDX, AMD SEV-SNP y AWS Nitro Enclaves, proporcionan cálculo aislado 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, incluido 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, confiados de 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 el cálculo 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 todavía 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 alto rendimiento como fuerte confidencialidad pre-comercio, actualmente representan el mejor compromiso de ingeniería disponible.

Construimos un prototipo funcional en Stellar usando Phala's TEE Cloud, que ofrece máquinas virtuales 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 órdenes 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 de 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 las operaciones.

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

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 se generó 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 digital criptográfica), una marca de tiempo y un desafío opcional proporcionado por el cliente. Este hash entra en el campo reportData de la cita de atestación, que luego firma el hardware de Intel.

La configuración de Docker Compose, incluido un digesto de imagen de contenedor fijado, también se hash y se 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 una Operación

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 atómicamente los saldos de las bóvedas: 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 Intel TDX genuino), integridad del código (el hash-compose prueba exactamente lo que se está ejecutando) y confinamiento de claves (las claves TLS y Stellar provienen de manera probada dentro 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 podría simplemente 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 obteniendo 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 manera 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 sistema operativo. 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 el pipeline de verificación para asegurar que toda la pila de software, no solo nuestro contenedor, coincida con los valores esperados.

Si estás construyendo infraestructura de trading preservando la privacidad, aquí está nuestra evaluación:

FHE: No viable para trading 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 de trading naturales. La escala 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 elecció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 trading preservando 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 que sus posiciones sean adelantadas, 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 atestiguación (incluida la verificación de cotización 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.