SA+L: autoridad de gasto y key image
El protocolo de Schnorr generalizado que sustituye a la "firma" en FCMP++
SA+L (Spend Authorization + Linkability, autorización de gasto + vinculabilidad) es una pequeña prueba sobre Ed25519 para cada entrada. Demuestra: «conozco x e y para la clave rerandomizada Õ, y la key image publicada L es igual a x·I para esa misma salida». Técnicamente es un protocolo de Schnorr generalizado (GSP): varias ecuaciones de Schnorr unidas por secretos compartidos.
Schnorr generalizado en un minuto
El Schnorr simple demuestra el conocimiento de un único x en una ecuación P = x·G. La versión generalizada demuestra el conocimiento de un vector de secretos (w₁, …, wₖ) que cumple varias ecuaciones lineales sobre puntos:
El protocolo es el mismo que para una sola clave:
- elegir
α_kaleatorios y publicarA_j = Σ α_k·X_{j,k}para cada ecuación; - desafío
c = Hs(todo lo publicado); - respuestas
s_k = α_k + c·w_k; - comprobación:
Σ s_k·X_{j,k} = A_j + c·Y_jpara cadaj.
El detalle clave: la misma respuesta s_k se usa en todas las ecuaciones donde aparece w_k. Así el verificador no aprende solo que «conoce algunos secretos», sino que «conoce los mismos secretos en todas las ecuaciones». Así es como se vinculan la autoridad de gasto y la key image.
Qué ecuaciones demuestra SA+L
Públicos: Õ, Ĩ, R, L y los generadores G, T, U, V. Los secretos de quien gasta: x, y (clave de la salida) y r_o, r_i, r_r_i (la «pintura» de la rerandomización). Simplificando, SA+L demuestra el sistema:
R = r_i·V + r_r_i·T
L = x·Ĩ − (x·r_i)·U la última es L = x·(Ĩ − r_i·U) = x·I; el producto x·r_i se introduce como un secreto aparte, y el vínculo con R impide falsificarlo
Las ecuaciones exactas de la especificación son algo distintas (tratan con cuidado qué productos de secretos hacen falta y cómo evitar filtraciones), pero la idea es exactamente esta: una sola prueba en la que x a la vez «abre» Õ y «produce» L.
Por qué no simplemente una firma
En RingCT, CLSAG hacía tres cosas a la vez: ocultaba la entrada en un anillo, demostraba la autoridad de gasto y vinculaba la key image. En FCMP++ la prueba de pertenencia se encarga de la primera tarea. Quedan dos, que se resuelven con un protocolo mucho más sencillo. Esto aporta:
- tamaño pequeño: unos pocos puntos y escalares por entrada;
- separación de funciones: el dispositivo que guarda la clave (un monedero de hardware) puede calcular SA+L, mientras un ordenador sin la clave construye la pesada prueba de pertenencia;
- secreto hacia adelante (forward secrecy): gracias a
y·Ten la clave (ver la visión general); - base para multisig: la estructura lineal de GSP se reparte bien entre varios firmantes (esquemas tipo FROST).
Qué se firma
El desafío c incluye un hash de toda la transacción (prefijo, salidas, compromisos), igual que en CLSAG. Por eso SA+L también actúa como firma: si se cambia un solo byte de la transacción después de firmarla, la prueba deja de verificarse.
Las definiciones formales están en el artículo de Luke Parker sobre FCMP++ y en la implementación en Rust (el proyecto monero-oxide). El protocolo y la implementación pasaron auditorías externas; los enlaces a los informes están recopilados en las discusiones del Monero Research Lab en GitHub.