Sassafras: un solo productor por slot, en secreto

Un equipo mide los intervalos entre bloques de su red BABE durante una semana. El promedio coincide con la duración del slot, pero la distribución no: hay huecos de dos y tres slots, y de vez en cuando dos bloques compiten por la misma altura. Alguien propone pasarse a Aura, que produce un bloque por turno con regularidad de reloj. Otro responde que con Aura cualquiera sabe quién produce el bloque de las 10:00:06, y que un atacante puede tumbar a ese nodo un segundo antes.

Sassafras intenta quedarse con lo mejor de ambos lados: exactamente un productor por slot, como Aura, y un productor desconocido hasta que produce, como BABE. Este capítulo explica cómo lo consigue y, con el mismo cuidado, en qué estado está dentro del Polkadot SDK. Spoiler honesto: es un componente experimental, sin cliente de nodo en la rama principal.

Preguntas guía

• ¿Qué problema de BABE y qué problema de Aura intenta resolver Sassafras a la vez?
• ¿Qué es un ticket y por qué necesita una prueba de pertenencia a un anillo?
• ¿Para qué sirve el repetidor y qué pasa si no colabora?
• ¿Qué existe hoy en el Polkadot SDK y qué no?

Conexiones dentro de la serie

• Antes: BABE explicó la lotería con VRF y sus slots vacíos o múltiples. Slots y Aura explicó los turnos fijos.
• Investigación relacionada: Vectores de ataque BFT muestra por qué un líder conocido de antemano es un blanco. Privacidad y pruebas de conocimiento cero en consenso da el contexto de las pruebas que usa el ticket.
• Después: BEEFY vuelve a la finalidad, esta vez para puentes. Antes, XCM cerró la parte de interoperabilidad.

El problema: regularidad o secreto

Las dos familias de producción por slots que ya viste fallan en lugares opuestos. En BABE, la asignación es aleatoria, así que un slot puede tener varios ganadores o ninguno. La investigación de la Web3 Foundation lo resume con una imagen de fábrica de pan: los bloques salen "at unpredictable intervals, due to having multiple eligible block producers at once, or none at all." [1]

Aura resuelve la regularidad con turnos fijos, pero paga en seguridad. El mismo texto advierte que si los productores se designan de forma no aleatoria y a intervalos fijos, "the chain becomes vulnerable to forking and denial-of-service attacks." [1] Saber quién produce el próximo bloque es saber a quién atacar.

La categoría que resuelve ambas cosas se llama elección secreta de líder único (SSLE, single secret leader election): un solo líder por turno, y nadie salvo él sabe que lo es hasta que actúa. La misma fuente reconoce que las propuestas previas tenían problemas de eficiencia y que "none have been deployed to date". [1] Sassafras es la propuesta de la Web3 Foundation para que una SSLE sea práctica.

El código del pallet define el objetivo con precisión de ingeniería: Sassafras "is a constant-time block production protocol that aims to ensure that there is exactly one block produced with constant time intervals rather than multiple or none." [2] Fíjate en el verbo: aims. Es una meta de diseño, no una garantía demostrada en producción.

El ticket: una lotería que no revela al ganador

La idea base es una lotería por época. Todos los validadores evalúan una VRF sobre la misma entrada aleatoria y publican el resultado: ese valor es su ticket. El pallet lo describe así: cada validador firma la misma entrada VRF y publica la salida, que "is their lottery ticket that can be validated against their public key." [2]

Hasta ahí, sería BABE con el resultado adelantado. El problema es evidente: si el ticket se valida contra la clave pública del validador, todos saben de quién es. El siguiente paso del pallet es justamente ocultar la clave: "We want to keep lottery winners secret, i.e. do not publish their public keys."

Pero sin clave pública, ¿cómo se evita que alguien publique tickets falsos y reserve slots que nunca usará? Cada slot reservado por un ticket falso sería un slot vacío, que es justo lo que el protocolo quería eliminar. La respuesta es una prueba de conocimiento cero que acompaña al ticket. El pallet la enuncia en lenguaje llano: "Here's my VRF output that has been generated using the given VRF input and my secret key. I'm not telling you my keys, but my public key is among those of the nominated validators". [2]

Esa construcción tiene nombre: ring VRF, una VRF cuya prueba demuestra pertenencia a un "anillo" de claves sin señalar cuál. La investigación lo presenta como la novedad del protocolo: usa una ring VRF para elegir un único productor por bloque "while maintaining sufficient block producer secrecy within a “ring” of all participants." [1] En el SDK, los primitivos de Sassafras declaran claves Bandersnatch (app_crypto!(bandersnatch, SASSAFRAS)) y exponen el contexto del anillo por runtime API. [3]

Cuando llega su slot, el ganador demuestra que el ticket era suyo y produce el bloque. La nota técnica de la Web3 Foundation describe ese reclamo como una prueba no anónima de que la salida es de su VRF, que los demás nodos verifican al validar el bloque. [4] El secreto dura exactamente hasta el momento en que ya no sirve atacarlo.

El repetidor y el orden outside-in

Una prueba de pertenencia no basta si el validador publica su propio ticket: la transacción delataría al emisor. Por eso el ticket viaja primero a otro validador. El pallet lo dice en una línea: "To anonymously publish the ticket to the chain a validator sends their tickets to a random validator who later puts it on-chain as a transaction." [2] La investigación llama a ese intermediario repeater, "an identity guard". [1]

¿Y si el repetidor no colabora? La nota técnica prevé que, si el ticket no aparece en cadena antes de cierto bloque, el propio validador lo publica. [4] Pierde el anonimato de ese ticket, pero no el slot. Es un buen ejemplo de diseño defensivo: el camino privado es el normal, el público es la red de seguridad.

En cadena, el pallet recibe los tickets con la llamada submit_tickets, verifica la prueba de anillo y los acumula como candidatos ordenados para la próxima época. La asignación final a slots no sigue el orden de los tickets: "The assignment is computed dynamically using an outside-in strategy." [2]

Outside-in significa que los tickets se reparten desde los extremos de la época hacia el centro. La nota técnica da el ejemplo (1,2,3,4,5) → (2,4,5,3,1). Si hay menos tickets que slots, los huecos quedan en el medio, y la nota indica que para esos slots "we use AuRa". [4] Para que eso sea raro, el protocolo pide más tickets que slots: un factor de redundancia x = 2.

Figura 1

Sassafras: de los tickets secretos al orden de la época

Fuentes:

[1][2][4]

Cómo leer esta figura

Fila superior con cuatro cajas encadenadas bajo el título época N: A, ticket con ring VRF y prueba de pertenencia; B, repetidor, cifrado para un validador al azar; C, on-chain, lo publica el repetidor con submit_tickets; D, orden, tickets ordenados con asignación outside-in. Desde D baja una flecha rotulada fija el orden hacia una llave que cubre la fila de la época N+1. Esa fila tiene siete casillas en orden t2, t4, t6, Aura en rojo, t5, t3 y t1, unidas por flechas. Un texto explica que cada slot tiene un ticket que su ganador reclama al producir y que si faltan tickets los slots del medio quedan para Aura. Un recuadro rojo final indica que en el Polkadot SDK existen pallet-sassafras y sp-consensus-sassafras, marcados como experimentales, y que no hay crate de cliente sc-consensus-sassafras en master.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Hay una diferencia de calendario entre las fuentes que conviene no ocultar. El pallet habla de tickets para la próxima época; la nota técnica, más antigua en su formulación, consume en la época m+2 los tickets generados en la época m. Para un lector, la idea es la misma: el orden se fija antes de que empiece la época que lo usa. Para quien implemente, el calendario exacto es el del código, y queda a validar contra la versión del pallet que se use.

Lo que existe en el Polkadot SDK, y lo que no

Este es el punto donde un capítulo sobre Sassafras puede engañar sin querer, así que vamos por partes y con fuentes.

Existe un pallet. substrate/frame/sassafras está en el repositorio, y su README advierte: "The crate interfaces and structures are experimental and may be subject to changes." [5] El mismo README enlaza un issue de seguimiento y una propuesta de RFC de la Fellowship (número 26).

Existen primitivos. substrate/primitives/consensus/sassafras define el identificador de motor SASS, las claves y la runtime API. [3]

No existe un cliente de nodo en master. No hay substrate/client/consensus/sassafras: la ruta responde 404 y el Cargo.toml del workspace solo lista el pallet y los primitivos (comprobado el 13 de noviembre de 2026). Sin ese crate no hay slot worker, verificador ni import queue para Sassafras, es decir, nada de lo que en el capítulo de anatomía del consenso veremos que hace falta en el nodo. Con el código de master no se puede levantar una red que produzca bloques con Sassafras.

La adopción en Polkadot es una intención. La investigación dice que Polkadot "is set to replace" BABE y Aura por Sassafras, y que una especificación derivada, Safrole, se integró en el protocolo JAM. [1] El estado de despliegue de Sassafras en Polkadot, y el de la RFC 26, quedan a validar: no encontramos una fuente primaria que confirme su activación.

Qué cambia respecto de Ethereum

En la Beacon Chain de Ethereum, el proponente de cada slot sale de una semilla RANDAO ponderada por saldo efectivo, y desde Fulu la lista de proponentes de las próximas épocas se guarda en el estado. El capítulo La Beacon Chain desde cero lo detalla. El resultado es lo contrario del objetivo de Sassafras: el calendario de proponentes es público con antelación.

Una diferencia de fondo merece atención: en la Beacon Chain el calendario público es una decisión aceptada, mientras que Sassafras pone el secreto del productor en el centro del diseño. Ninguno de los dos resuelve la finalidad por sí solo: Sassafras, como dice su propia investigación, puede combinarse con otro protocolo, por ejemplo GRANDPA, para obtener finalidad definitiva. [1]

Cuándo vale la pena la complejidad

Volvamos al equipo del escenario. Sassafras ofrece intervalos regulares y productores ocultos, pero añade tres costes: una criptografía más pesada (pruebas de anillo con un contexto de configuración), un protocolo de publicación en dos saltos y una dependencia de componentes que hoy no tienen cliente de nodo.

Para una red privada con pocos validadores conocidos, el problema que Sassafras resuelve suele ser menor: los productores ya se conocen entre sí y la denegación de servicio se mitiga con red privada. Para una red pública grande, la regularidad del intervalo y el secreto del productor sí cambian el rendimiento y la superficie de ataque. La decisión no es "Sassafras sí o no", sino cuánto vale ese secreto frente a la madurez del código disponible.

Laboratorio propuesto

Estado: propuesta. Este laboratorio todavía no está publicado en lab.trautslab.dev; describe lo que se construirá, en local, sin red pública ni fondos reales. No ejecuta Sassafras, porque no hay cliente de nodo en master.

Objetivo. Medir el problema que Sassafras intenta resolver, con los dos motores que sí funcionan, y razonar qué cambiaría.

Pasos propuestos.

1. En la red BABE del laboratorio de BABE, registrar durante un periodo fijo el intervalo entre bloques consecutivos y contar slots vacíos y bloques en competencia.
2. Repetir la medición en la misma red con Aura.
3. Con los dos histogramas delante, discutir qué aportaría Sassafras sin ejecutarlo: qué forma tendría el histograma si la meta de un bloque por slot se cumpliera y qué información quedaría expuesta con Aura.

Evidencia esperada. Con Aura, intervalos concentrados en la duración del slot salvo cuando falta una autoridad. Con BABE, una distribución más ancha, con intervalos de varios slots y algunas alturas con dos bloques. La forma exacta depende del parámetro c de BABE y del número de autoridades, y queda a validar al construir el laboratorio.