Firmado

Recursos para Constructores

• Para operar como Firmante, aquí.

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

La Visión General

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

• Se seleccionan 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 papel refuerza la finalización y la seguridad de la red.

---

Introducción

Los Stackers, que también operan como Firmantes, juegan un papel esencial en la red Stacks (post-actualización Nakamoto) que previamente había sido responsabilidad de los mineros. Antes, los mineros tanto decidían el contenido de los bloques como si incluirlos en la cadena (es decir, decidiendo si confirmarlos o no). En este sistema cada actor tiene las siguientes responsabilidades necesarias para que el sistema funcione de manera confiable 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 está en separar estas dos preocupaciones mientras se garantiza que tanto la minería como el Stacking sigan siendo procesos de membresía abierta. Crucialmente, cualquiera puede convertirse en minero y cualquiera puede convertirse en Stacker, 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 hacerlo, los Stackers primero deben ponerse de acuerdo sobre la punta canónica de la cadena y luego aplicar (y revertir) el bloque en dicha 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 firmarlo. Si los Stackers no pueden ponerse de acuerdo sobre la punta canónica de Stacks, entonces ningún bloque se añadirá 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 pueden acordar la punta de la cadena— 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 e incentivándolos mediante recompensas PoX para que actúen como tales.

Firma por Stackers

El medio por el cual los Stackers acuerdan 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. 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 bloqueado 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 utilizan 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 tendrá éxito solo 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 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.

Aquí hay un diagrama que describe la relación entre la firma y el stacking.

---

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 precedentes 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 block-commit de su tenencia*

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

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

  • La raíz del estado coincide con la raíz MARF tip 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 block-commit 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 transacción TenureChange .

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

Las propiedades marcadas con * son colectivamente cómo Stacks garantiza la finalización de Bitcoin. Al adherirse a estas propiedades, se asegura que los mineros solo pueden 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, garantizan la finalización de Bitcoin.

Realización de Cambios de Tenencia de Mineros

La otra responsabilidad principal de firma en la producción de bloques implica llevar a cabo transacciones de cambio de tenencia. Como se discutió en la sección de minería, los mineros enviarán una transacción block-commit en la cadena de Bitcoin para iniciar la minería. Si son seleccionados, los stackers detectarán eso y crearán una transacción tenure-change .

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 subsiguientes; si esto ocurre, entonces este valor de hash de consenso permanece igual que en la sortición en la que se minó el block-commit ganador.	20 bytes
hash de consenso de la tenencia anterior	Hash de consenso de la tenencia anterior. Corresponde a la sortición del block-commit ganador anterior.	20 bytes
hash de consenso de la vista de burn	Hash de consenso actual en la burnchain subyacente. Corresponde a la última sortición vista.	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 sortición.	4 bytes, big-endian
causa	Una bandera 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 electo 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 exactamente lo que ocurre entre bastidores durante estos procesos.

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

---

Recursos Adicionales

• [StacksDevs YT] Taller de Firmantes del Lanzamiento Nakamoto de Stacks