Firma: Verificar la validez del bloque

Recursos del Constructor

• Para operar como Firmante, aquí.

• Para ver una lista completa de Firmantes activos, aquí.

La Gran Imagen

• Los firmantes validan y firman los bloques propuestos de Stacks.

• Son seleccionados de los Stackers elegibles en cada ciclo.

• Se requiere un umbral del 70% de firmas para que un bloque sea aceptado.

• Verifican la corrección del bloque antes de firmarlo.

• Firmar ayuda a prevenir bloques inválidos o en conflicto.

• Su rol refuerza la finalización y la seguridad de la red.

---

Introducción

Los Stackers, que también operan como Firmantes, desempeñan un papel esencial en la red Stacks (posterior a la actualización Nakamoto) que anteriormente había sido responsabilidad de los mineros. Antes, los mineros tanto decidían el contenido de los bloques como decidían si incluirlos o no en la cadena (es decir, al decidir si confirmarlos o no). En este sistema cada actor tiene las siguientes responsabilidades necesarias para que el sistema funcione de manera fiable sin bifurcaciones:

• Mineros deciden el contenido de los bloques.

• Firmantes deciden si el bloque se incluye o no en la cadena.

La mayor parte de la complejidad de los cambios de Nakamoto consiste en separar estas dos preocupaciones garantizando que tanto la minería como el Stacking sigan siendo procesos de membresía abierta. Crucialmente, cualquier persona puede convertirse en minero y cualquier persona puede convertirse en Stacker, tal como antes. Los cambios más sustanciales consisten en lograr que mineros y Stackers trabajen juntos en sus nuevos roles para alcanzar los objetivos de esta propuesta.

La idea clave es que los Stackers, como Firmantes, deben reconocer y validar el bloque de un minero antes de que pueda añadirse a la cadena. Para ello, los Stackers deben primero ponerse de acuerdo sobre la punta canónica de la cadena y luego aplicar (y revertir) el bloque sobre esa punta para determinar su validez. Una vez que los Stackers acuerdan que el bloque es tanto canónico como válido, lo firman colectivamente y lo replican al resto de la red de pares de Stacks. Solo en ese momento los nodos añaden el bloque a sus historiales de cadena.

Este nuevo comportamiento evita que surjan bifurcaciones. Si un minero construye un bloque sobre una punta obsoleta, los Stackers se negarán a firmar el bloque. Si los Stackers no pueden ponerse de acuerdo sobre la punta canónica de Stacks, entonces no se añadirá ningún bloque en primer lugar. Aunque este comportamiento crea un nuevo modo de fallo para Stacks —a saber, la cadena puede detenerse indefinidamente si los Stackers no se ponen de acuerdo sobre la punta— esto se mitiga manteniendo un cuerpo grande y diverso de Stackers de modo que suficientes de ellos estén en línea en todo momento para alcanzar el quórum y incentivándolos mediante recompensas PoX para que actúen como tal.

Firma por Stackers

El medio por el cual los Stackers se ponen de acuerdo sobre la punta canónica de la cadena y acuerdan añadir bloques está ligado a PoX. En cada ciclo de recompensas, un Stacker asegura uno o más espacios de recompensa; hay como máximo 4.000 espacios de recompensa por ciclo de recompensas. Los Stackers votan para aceptar bloques produciendo una firma de umbral ponderada sobre el bloque. La firma debe representar una fracción sustancial del total de STX bloqueado en PoX (el umbral), y la participación de cada Stacker en la firma (su peso) es proporcional a la fracción de STX bloqueada que posee.

La firma de umbral ponderada es una firma Schnorr generada mediante una variación del protocolo FROST. Cada Stacker genera un par de claves de firma, y colectivamente generan una clave pública agregada que los nodos usan para verificar las firmas calculadas mediante un protocolo de firma distribuida. Este protocolo de firma asigna participaciones de la clave privada agregada asociada a los Stackers en proporción al número de espacios de recompensa que aseguran. Ningún Stacker conoce la clave privada agregada; en su lugar, los Stackers calculan participaciones de la clave privada y las usan para calcular participaciones de una firma, que pueden combinarse en una única firma Schnorr.

Cuando un minero produce un bloque, los Stackers ejecutan un protocolo de firma distribuida para generar colectivamente una única firma Schnorr para el bloque. Crucialmente, el protocolo de firma solo tendrá éxito si al menos X% de los espacios de recompensa están contabilizados en la firma agregada. Nakamoto está actualmente configurado para usar un umbral de firma del 70%: al menos el 70% de los espacios de recompensa (por proxy, el 70% del STX apilado) deben firmar un bloque para poder añadirlo a la cadena de bloques de Stacks.

Nakamoto utiliza el protocolo WSTS con la extensión FIRE, que admite un par de algoritmos de generación de claves distribuidas y generación de firmas cuya complejidad de CPU y ancho de banda de red crece con el número de Stackers distintos. La extensión FIRE permite que WSTS tolere Stackers bizantinos.

La relación entre Stackers y Firmantes

Aquí hay un diagrama que describe la relación entre firmar y hacer stacking.

• No todos los stackers son firmantes → porque los stackers pueden delegar su participación (incluidas las responsabilidades de firma)

• Todos los firmantes están respaldados por su propio STX o STX delegado → para estar en el conjunto de firmantes, debes representar peso de STX apilado

---

Validación y Adición de Nuevos Bloques

Cuando se seleccionan mineros para una nueva tenencia, comienzan a construir nuevos bloques a partir de transacciones en el mempool. Luego envían esos bloques a los firmantes para su aprobación. Los firmantes deben aprobar los bloques con un quórum de al menos el 70% para que se añadan a la cadena.

Los firmantes aprobarán un bloque basándose en varias propiedades:

• El bloque está bien formado

  • Tiene la versión correcta y la bandera mainnet/testnet

  • Su encabezado contiene el número correcto de bloques de Stacks que preceden a este.

  • Su encabezado contiene el total correcto de Bitcoin gastados en la sortición que eligió la tenencia actual.

  • Su encabezado contiene el mismo hash de bloque de Bitcoin que el bloque de Bitcoin que contiene la transacción de commit de bloque de su tenencia*

  • Su encabezado contiene el ID del bloque padre correcto del padre inmediato de este bloque.*

  • La raíz del árbol Merkle de transacciones es consistente con las transacciones

  • El hash raíz de estado coincide con el hash raíz punta MARF una vez aplicadas todas las transacciones

  • El encabezado del bloque tiene una firma ECDSA válida del minero.

  • El encabezado del bloque tiene una firma Schnorr WSTS válida del conjunto de Stackers.

• Todas las transacciones de Bitcoin desde la última sortición válida hasta (pero sin incluir) el bloque de Bitcoin del commit del bloque de esta tenencia se han aplicado al estado de la cadena Stacks*

• En el caso de un bloque de inicio de tenencia:

  • La primera transacción es la TenureChange transacción.

  • La primera transacción después de la TenureChange transacción es una Coinbase.

Las propiedades marcadas con * son, colectivamente, la forma en que Stacks garantiza la finalización en Bitcoin. Al adherirse a estas propiedades, se asegura de que los mineros solo puedan añadir bloques si construyen sobre la punta de cadena correcta, lo que también ancla la historia a Bitcoin.

Los firmantes, al validar estas reglas, aseguran la finalización en Bitcoin.

Realización de Cambios de Tenencia de Mineros

La otra responsabilidad principal de firma en la producción de bloques implica realizar las transacciones de cambio de tenencia. Como se discutió en la sección de minería, los mineros enviarán una transacción de commit de bloque en la cadena de Bitcoin para iniciar la minería. Si son seleccionados, los stackers lo detectarán y crearán un cambio de tenencia transacción.

Esta transacción de cambio de tenencia incluye:

Nombre	Descripción	Representación
hash de consenso de la tenencia	Hash de consenso de esta tenencia. Corresponde a la sortición en la que se eligió al minero de este bloque. Puede darse el caso de que la tenencia de este minero se extienda a través de sorticiones posteriores; si esto ocurre, entonces este valor de hash de consenso permanece igual que en la sortición en la que se minó el commit de bloque ganador.	20 bytes
hash de consenso de la tenencia anterior	Hash de consenso de la tenencia anterior. Corresponde a la sortición del commit de bloque ganador anterior.	20 bytes
hash de consenso de la vista de quema	Hash de consenso actual en la burnchain subyacente. Corresponde a la sortición vista por última vez.	20 bytes
fin de la tenencia anterior	El hash del bloque índice del último bloque de Stacks de la tenencia anterior.	32 bytes
bloques de la tenencia anterior	El número de bloques producidos desde la última tenencia vinculada a una sortición.	4 bytes, big-endian
causa	Una marca para indicar la causa de este cambio de tenencia - 0x00 indica que ocurrió una sortición, y un nuevo minero debe comenzar a producir bloques. - 0x01 indica que el minero actual debe continuar produciendo bloques. El presupuesto de ejecución de la tenencia del minero actual se restablece al procesar esta transacción.	1 byte
hash de pubkey	El hash de la clave pública ECDSA de la tenencia actual.	20 bytes

Esta transacción de cambio de tenencia se envía entonces al minero recién elegido y debe incluirla como la primera transacción en su primer bloque, de lo contrario los stackers no la aprobarán.

Este proceso se repite una y otra vez a medida que se eligen nuevos mineros para las tenencias.

Asegúrate de echar un vistazo a SIP-021 para obtener una descripción detallada de lo que exactamente ocurre entre bastidores durante estos procesos.

A continuación, profundicemos un poco más en esta idea de la finalización de Bitcoin y en cómo el mecanismo de producción de bloques de Stacks lo logra.

---

Recursos Adicionales

• [StacksDevs YT] Taller de Firmantes de la Versión Nakamoto de Stacks