Resumen Técnico: PACE – Autorización Multipartita Vinculada a Políticas con Ejecución Consistente de Estado para Contratos Inteligentes

1. Declaración del Problema

Los contratos inteligentes que gobiernan operaciones sensibles (por ejemplo, transferencias de activos, cambios de permisos) a menudo requieren autorización multipartita. Sin embargo, los mecanismos existentes frecuentemente tratan las actualizaciones de políticas, el vínculo de solicitudes y la gestión del ciclo de vida de la autorización como preocupaciones separadas. Esta separación crea una brecha crítica en la consistencia de extremo a extremo de la autorización.

Específicamente, el artículo identifica cuatro retos de investigación (RQ) derivados de la separación entre la aprobación fuera de la cadena (off-chain) y la ejecución dentro de la cadena (on-chain):

1. Consistencia entre Política y Decisión (RQ1): Cómo asegurar que una aprobación conjunta siga siendo válida si la política activa o la configuración de autoridad cambia (por ejemplo, una actualización de los firmantes requeridos) antes de la ejecución.
2. Vínculo entre Decisión y Solicitud (RQ2): Cómo garantizar que la solicitud enviada al contrato sea idéntica a la aprobada por las autoridades, evitando que un solicitante malicioso altere los parámetros de la llamada o el contrato objetivo.
3. Gestión del Ciclo de Vida de la Autorización (RQ3): Cómo prevenir el reuso de autorizaciones expiradas, consumidas o inválidas en el momento de la ejecución.
4. Consistencia entre Autorización y Ejecución (RQ4): Cómo acoplar atómicamente el consumo de una autorización con la ejecución de la operación protegida, asegurando que una operación fallida no deje la autorización como "gastada" o que una operación exitosa proceda sin consumo.

Las soluciones existentes como SMACS (basada en tokens) o X-LOCK (basada en atributos descentralizados) abordan subconjuntos de estos problemas, pero no logran integrar la aprobación conjunta de una invocación específica con los cuatro requisitos de consistencia dentro de un único ciclo de vida.

2. Metodología: El Marco de Trabajo PACE

Los autores proponen PACE, un marco que vincula la autorización multipartita a una instancia de política específica y fuerza la consistencia de estado a través de un flujo de trabajo unificado.

2.1 Modelo de Sistema y Flujo de Trabajo

El sistema involucra a un Propietario de la Política (PO), un conjunto de $n$ Autoridades ($A$), un Solicitante ($U$) y un Contrato Inteligente (SC) que actúa como puerta de enlace de ejecución.

1. Establecimiento de Configuración: El PO define una política $P$ y registra las claves públicas de las autoridades. Un proceso de activación atómica crea una configuración específica por época que vincula la política con el conjunto actual de claves de verificación.
2. Autorización Conjunta Vinculada al Contexto: El solicitante envía una solicitud fuera de la cadena. Las autoridades revisan un contexto de ejecución canónico ($\mu_{SC}$) que incluye el dominio, la versión de la política, el contrato objetivo, la operación, los datos de la llamada, el ID de sesión, el nonce y la fecha límite.
   • Las autoridades utilizan un esquema de firma múltiple de dos rondas basado en redes (DualMS) para generar evidencia conjunta.
   • El esquema opera en un modo $n$-de-$n$, requiriendo que todas las autoridades designadas aprueben y participen.
3. Ejecución con Consistencia de Estado: El solicitante envía la solicitud y la firma conjunta al SC. La puerta de enlace realiza:
   • Validación de Política: Verifica la firma contra la configuración de política actual activa, no contra la utilizada durante la firma.
   • Coincidencia de Contexto: Asegura que la solicitud enviada coincida exactamente con el contexto firmado.
   • Verificaciones de Estado: Verifica la frescura (nonce, fecha límite) y comprueba si el ID de sesión ha sido utilizado.
   • Ejecución Atómica: Si todas las comprobaciones pasan, el contrato marca atómicamente la sesión como usada y ejecuta la operación protegida. Si la operación falla, la transacción revierte, incluyendo el registro de consumo.

2.2 Fundamento Criptográfico

PACE utiliza DualMS, una construcción de firma múltiple de dos rondas basada en redes (Chen 2023). Esta elección respalda los objetivos de seguridad post-cuántica. El protocolo se basa en:

• Codificación Canónica: Todos los campos del contexto se codifican y se pasan por una función hash para formar el mensaje $m$.
• Muestreo de Rechazo (Rejection Sampling): Utilizado durante el proceso de firma para prevenir la filtración de la clave secreta, lo que requiere reintentos si las muestras caen fuera de los límites de norma específicos.
• Modelo de Seguridad de Clave Pública Objetivo: El análisis de seguridad asume una autoridad objetivo ($A_1$) no corrompida dentro de la configuración, mientras que los adversarios pueden controlar otras autoridades.

3. Contribuciones Clave

El artículo realiza tres contribidades primarias:

1. Formalización de la Consistencia: Los autores definen y analizan formalmente tres propiedades de seguridad bajo un experimento de clave pública objetivo:

   • Consistencia entre Política y Decisión: Asegura que la ejecución solo ocurra si la política activa coincide con la que rige la aprobación.
   • Vínculo entre Decisión y Solicitud: Asegura que la solicitud ejecutada coincida con el contexto firmado.
   • Consistencia entre Autorización y Ejecución: Asegura que la transición de estado (consumo) esté inextricablemente ligada a la ejecución exitosa de la operación específica.
   • El análisis demuestra que la ejecución no autorizada implica ya sea una falsificación de la firma conjunta (rompiendo la seguridad UF-CMA de DualMS) o una colisión en la función hash del contexto.

2. Construcción de PACE: El marco integra la interfaz criptográfica con la semántica de los contratos inteligentes. Introduce un mecanismo donde la puerta de enlace recupera la clave de verificación del estado actual del contrato, evitando el uso de firmas generadas bajo configuraciones obsoletas. Fuerza la atomicidad al acoplar la actualización del estado "Usado" con la llamada protegida.

3. Evaluación del Prototipo: Se implementó un prototipo en Python/SageMath para evaluar el sistema.

   • Verificaciones de Consistencia: El prototipo verificó que las políticas obsoletas, las solicitudes modificadas y las sesiones repetidas son rechazadas correctamente.
   • Ablaciones Semánticas: Eliminar comprobaciones específicas (por ejemplo, coincidencia de política o comprobaciones de un solo uso) en el prototipo condujo a los fallos de seguridad esperados, validando la necesidad de cada componente.
   • Rendimiento: El sistema se evaluó contra un número variable de autoridades ($n=4$ a $32$) y longitudes de datos de llamada.

4. Resultados

La evaluación del prototipo arrojó los siguientes hallazgos:

• Costo Computacional:

  • Factor Dominante: La firma colaborativa (generación y agregación) representa la mayor parte del costo computacional. A medida que aumenta el número de autoridades ($n$), el tiempo de agregación escala significativamente (de ~1.09s con $n=4$ a ~8.10s con $n=32$).
  • Verificación Estable: El tiempo de verificación en el contrato permanece relativamente estable (~0.71–0.73s) independientemente de $n$, ya que verifica una única firma agregada en lugar de mensajes individuales.
  • Impacto del Contexto: El aumento de la longitud de los datos de la llamada (hasta 12,800 bits) tuvo un impacto insignificante en los tiempos de computación criptográfica, ya que las dimensiones de la red permanecen fijas y el contexto se pasa por un hash a un mensaje de longitud fija.
  • Sobrecarga (Overhead): La sobrecarga incremental del marco de trabajo PACE sobre las operaciones criptográficas centrales de DualMS es pequeña (por ejemplo, ~0.18s con $n=32$), lo que indica que las comprobaciones de política y estado son computacionalmente eficientes en relación con las operaciones de red.

• Comunicación y Almacenamiento:

  • Comunicación: La comunicación total crece linealmente con el número de autoridades debido al tráfico de coordinación (recolección de compromisos y respuestas), variando desde ~30 MiB ($n=8$) hasta ~110 MiB ($n=32$). El tamaño de la firma agregada permanece constante.
  • Almacenamiento: El almacenamiento de la configuración (estado de la autoridad y estado de la autorización) crece linealmente con $n$, alcanzando aproximadamente 1.07 MB para $n=32$.

• Comportamiento de Reintento:

  • El mecanismo de muestreo de rechazo requiere reintentos para evitar la filtración de secretos. Con un presupuesto de reintento ($R$) de 6 a 8, la probabilidad de éxito para el núcleo criptográfico completo supera el 0.80, estabilizándose cerca de 0.90 con $R=10$.

5. Significación y Reivindicaciones

El artículo afirma que PACE aborda el manejo fragmentado de la autorización en los sistemas de contratos inteligentes existentes al proporcionar un ciclo de vida unificado que garantiza la consistencia de extremo a extremo.

• Integración: A diferencia de trabajos previos que manejan la política, el vínculo o el ciclo de vida por separado, PACE integra la aprobación conjunta de una invocación específica con la comprobación de la política activa y las transiciones de estado atómicas.
• Seguridad: El marco proporciona garantías formales de que la ejecución no autorizada es computacionalmente inviable bajo los supuestos establecidos (seguridad de DualMS y resistencia a colisiones), específicamente previniendo la ejecución bajo políticas obsoletas o con solicitudes alteradas.
• Preparación Post-Cuántica: Al utilizar criptografía basada en redes, el marco está diseñado con la seguridad post-cuántica en mente, aunque la prueba formal permanece en el modelo de oráculo aleatorio clásico.

Los autores mantienen una postura modesta, señalando que la implementación actual asume un modelo $n$-de-$n$, una gestión de configuración de confianza y semánticas de ejecución atómica. Declaran explícitamente que el prototipo fue simulado y no mide la latencia específica de la blockchain ni los costos de gas, identificando estas como áreas para el trabajo futuro.