Retiro de activos

La interoperabilidad es fundamental para que las appchains maximicen su alcance, utilidad y experiencia de usuario. El sistema de retiro de Syndicate combina un Entorno de Ejecución Confiable (TEE) con una atestación verificada por zk para permitir una verificación sin permisos y no interactiva. Al reemplazar las pruebas de fraude basadas en desafíos, ofrece una finalidad casi instantánea con seguridad de puente nativo, combinando la velocidad de los puentes rápidos con la seguridad de los puentes canónicos, sin bifurcaciones ni sobrecarga operativa adicional.

Fundamento del diseño

Nuestra capa de secuenciación personalizada cambia la forma en que las transacciones son procesadas, ordenadas y derivadas, lo que creó dos opciones:

1. Bifurcar Arbitrum Orbit y personalizar su sistema de prueba de fraude (viola nuestro principio de no bifurcación, retrasa actualizaciones y requiere trabajo personalizado para cada framework de rollup)
2. Construir una solución generalizable que funcione con cualquier framework de rollup (sin bifurcaciones, sin pruebas de fraude personalizadas)

Elegimos la solución generalizable.

Componentes principales

TEE (AWS Nitro):

Proporciona un enclave de cómputo seguro. (Nota: AWS Nitro TEE, no Arbitrum Nitro)

• Función: Ejecuta la derivación, verifica las transiciones de secuenciación/appchain y genera una afirmación de retiro firmada.
• Confianza: Solo los enclaves cuya atestación (mediciones PCR) es verificada por zk están incluidos en la lista blanca en la cadena.
• Verificación en cadena: TeeModule verifica las firmas ECDSA; TeeKeyManager acepta claves probadas por el verificador zk.
• Experiencia del desarrollador: Usa el puente nativo como siempre; los proponentes interactúan con el enclave. Las actualizaciones solo requieren volver a atestar/incluir claves en la lista blanca, no cambios en la aplicación.

zkVM (Succinct SP1)

• Función: Demuestra que la atestación de AWS Nitro es válida sin revelar el documento completo.
• En cadena: AttestationDocVerifier verifica las pruebas SP1 (Groth16/Plonk) y aplica el certificado raíz esperado, PCRs y ventana de validez, devolviendo el tee_signing_key para la lista blanca.
• Salidas públicas: Hash del certificado raíz, ventana de validez, PCR0/1/2 y tee_signing_key.
• Experiencia del desarrollador: No necesitas llamar al zkVM. Un presentador de pruebas genera la prueba y registra/rota las claves del enclave en la cadena.

Flujo del proceso de retiro

[User/Appchain] -- withdrawal request
      |
      v
[Proposer] -- validate request + build trusted input
      |
      v
[TEE Enclave] -- verify state + sign assertion --> [TeeModule on settlement]
      |
      |-- attestation verified on-chain -------> [TeeKeyManager + zk verifier]
      |
[TeeModule] -- finalize -----> posts to rollup (e.g., Base) -> withdrawals enabled

1. Recepción de solicitud: El sistema recibe la solicitud de retiro
2. Validación y aprobación:
   • Confirma que todas las transiciones de estado en la solicitud de retiro son válidas
   • Verifica que la solicitud de retiro esté comprometida como una raíz de estado de manera resistente a la reorganización en la cadena de liquidación
   • Realiza comprobaciones estándar: verificación del saldo del usuario, validez del estado, moneda del estado
3. Firma TEE: Si se valida, el TEE firma con su clave interna
4. Validación de clave: La clave del TEE se considera válida porque la atestación ZKVM la ha validado
5. Integración con el puente: Se conecta al puente nativo de Arbitrum a través de su mecanismo de retiro rápido (utilizando la interfaz del Comité de Disponibilidad de Datos, pero con nuestro sistema de retiro proporcionando las aprobaciones en lugar de una capa DA). No hay modificaciones al puente de Arbitrum en sí.

Beneficios clave

• Agnóstico al framework: Funciona con cualquier framework de rollup sin personalización
• Sin mantenimiento de bifurcaciones: Los clientes pueden incorporar inmediatamente las actualizaciones de Arbitrum Orbit
• Seguridad de puente nativo: No hay un puente personalizado para mantener los fondos. Los fondos se mantienen en el puente de Arbitrum y se utiliza la funcionalidad existente para habilitar los retiros
• Seguridad escalable: Retiros rápidos con mecanismos de desafío para casos disputados
• Operación descentralizada: Los TEE pueden ser ejecutados por cualquiera, no solo por el equipo principal
• Redundancia multi-proveedor: La futura arquitectura multi-TEE/multi-zkVM previene puntos únicos de fallo

Estado actual

• El sistema de retiro está actualmente en desarrollo
• Comenzando con un TEE y una implementación zkVM
• Se añadirán progresivamente proveedores adicionales

Nota: Este es un nuevo sistema en desarrollo. La arquitectura es estable, pero los detalles pueden evolucionar. Para preguntas o comentarios, contacta al equipo de Syndicate.

1. Período de impugnación: El intervalo durante el cual se pueden disputar los retiros (configurable por el propietario de la chain, se recomiendan 60 minutos)
2. Intervalo de publicación por lotes: Con qué frecuencia se publican los lotes de retiros en L1 (1 hora)
3. Finalización de L1: La finalidad de Ethereum L1 toma aproximadamente 12,8 minutos

La variabilidad en el tiempo de retiro depende de dónde cae tu retiro dentro de la ventana de publicación por lotes. Si lo envías justo antes del próximo lote por hora, obtienes el tiempo mínimo. Si lo envías justo después de que se publique un lote, deberás esperar al siguiente ciclo de lotes.

Período de impugnación de 60 minutos (recomendado)

Con un período de impugnación de 60 minutos:

El período de impugnación de 60 minutos proporciona fuertes garantías de seguridad y tiempo suficiente para que los validadores TEE detecten y marquen retiros inválidos. Los retiros no impugnados se completan en menos de 3,5 horas.

Períodos de impugnación más cortos

El período de impugnación puede ser configurado por el propietario de la chain en cualquier momento, pero los períodos más cortos aumentan el riesgo operativo. Los propietarios de la chain pueden usar opcionalmente un contrato de timelock para gestionar los cambios en el período de impugnación. Una ventana más corta significa menos tiempo para que los validadores TEE detecten e impugnen retiros inválidos—si los validadores TEE experimentan tiempo de inactividad durante un período de impugnación corto, los retiros inválidos podrían quedar sin impugnar.

Por ejemplo, con un período de impugnación de 5 minutos:

Aunque esto ofrece retiros no impugnados más rápidos, la ventana reducida requiere mayores garantías de tiempo de actividad de los validadores TEE.

Retiros impugnados

Las impugnaciones son iniciadas por los validadores TEE cuando detectan un retiro inválido (lo que indica un error o un compromiso del TEE). Los retiros impugnados se envían a un consejo de seguridad para su resolución manual. Como las disputas son poco frecuentes, este proceso opera fuera de las expectativas normales de tiempo mencionadas anteriormente.

Puentes instantáneos y experiencia del usuario

En la práctica, la mayoría de las rutas de puente utilizan puentes instantáneos que abstraen el tiempo de retiro para los usuarios finales. Los usuarios ven que los retiros se completan en segundos con un deslizamiento mínimo. El tiempo de retiro subyacente solo afecta la rapidez con la que el puente instantáneo puede reequilibrar su liquidez.

Para el reequilibrio de puentes instantáneos, los retiros de menos de 4 horas son más que suficientes. Esto significa que el tiempo técnico de retiro tiene un impacto mínimo en la experiencia real del usuario cuando se integran puentes instantáneos.

Restricción de finalidad de L1

Los retiros no pueden ser más rápidos que la finalización de Ethereum L1 (~12,8 minutos). Intentar procesar retiros en bloques no finalizados introduce riesgo de reorganización—Ethereum L1 experimenta reorganizaciones aproximadamente una vez cada dos horas, lo que podría causar pérdida de fondos.

Fórmula de tiempo

Como referencia, los tiempos de retiro pueden calcularse como:

Min:     1   × challenge period + 0   × batch interval + 12.8 min
Average: 1.5 × challenge period + 0.5 × batch interval + 12.8 min
Max:     2   × challenge period + 1   × batch interval + 12.8 min

Estado actual

• El sistema de retiro está habilitado
• Comenzando con un proveedor TEE y una implementación zkVM
• Se añadirán proveedores adicionales progresivamente

Nota: Este es un nuevo sistema en desarrollo. La arquitectura es estable, pero los detalles pueden evolucionar. Para preguntas o comentarios, contacta al equipo de Syndicate.