# Firma: verificación de la validez del bloque
{% hint style="info" %}
**Recursos para desarrolladores**
* Para operar como firmante, [aquí](/operate/run-a-signer.md).
* Para ver una lista completa de firmantes activos, [aquí](https://explorer.hiro.so/signers?chain=mainnet).
{% endhint %}
#### La visión general
* Los firmantes validan y firman los bloques propuestos de Stacks.
* Son seleccionados de entre 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.
* La firma ayuda a evitar bloques inválidos o en conflicto.
* Su función fortalece la finalidad 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 (después de la actualización Nakamoto) que antes era responsabilidad de los mineros. Antes, los mineros decidían tanto el contenido de los bloques como si debían o no incluirse en la cadena (es decir, decidiendo si debían o no confirmarse). En este sistema, cada actor tiene las siguientes responsabilidades necesarias para que el sistema funcione de forma 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 reside en separar estas dos preocupaciones, garantizando al mismo tiempo que tanto la minería como el stacking sigan siendo procesos de membresía abierta. **Y lo que es crucial, cualquiera puede convertirse en minero y cualquiera puede convertirse en Stacker, igual que antes.** Los cambios más sustanciales consisten en conseguir que mineros y Stackers trabajen juntos en sus nuevos roles para lograr 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 deben primero ponerse de acuerdo sobre la punta canónica de la cadena y luego aplicar (y revertir) el bloque sobre esa punta de la cadena para determinar su validez. Una vez que los Stackers acuerdan que el bloque es canónico y válido, lo firman colectivamente y lo replican al resto de la red P2P de Stacks. Solo en ese momento los nodos añaden el bloque al historial de sus cadenas.
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 pueden ponerse de acuerdo sobre la punta de la cadena—, esto se mitiga teniendo un conjunto grande y diverso de Stackers, de modo que suficientes de ellos estén en línea en todo momento para alcanzar quórum, y se les incentive mediante recompensas PoX a actuar como tal.
## Firma de Stackers
El medio por el cual los Stackers se ponen de acuerdo sobre la punta canónica de la cadena y sobre la adición de bloques está vinculado a PoX. En cada ciclo de recompensas, un Stacker asegura una o más plazas de recompensa; hay como máximo 4.000 plazas 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 bloqueados en PoX (el umbral), y la parte de la firma de cada Stacker (su peso) es proporcional a la fracción de STX bloqueados que posee.
La firma de umbral ponderada es una firma Schnorr generada mediante una variación del [protocolo FROST](https://eprint.iacr.org/2020/852.pdf). Cada Stacker genera un par de claves de firma, y colectivamente generan una clave pública agregada para que los nodos la utilicen para verificar 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 plazas 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 sola 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. Y lo que es crucial, el protocolo de firma solo tendrá éxito si al menos el X% de las plazas de recompensa se tienen en cuenta en la firma agregada. Actualmente, Nakamoto está configurado para usar un umbral de firma del 70%: al menos el 70% de las plazas de recompensa (por extensión, el 70% de los STX en stacking) 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](https://trust-machines.github.io/wsts/wsts.pdf), que admite una pareja de algoritmos de generación distribuida de claves y de 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 a WSTS tolerar Stackers bizantinos.
#### La relación entre Stackers y firmantes
Aquí hay un diagrama que describe la relación entre la firma y el 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 **sus propios STX** o **STX delegados**\
→ para formar parte del conjunto de firmantes, debes representar **peso de STX en stacking**
***
## Validación y adición de nuevos bloques
Cuando se selecciona a los mineros para una nueva tenencia, comienzan a construir nuevos bloques a partir de las transacciones del 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 en función de varias propiedades:
* El bloque tiene una forma correcta
* Tiene la versión correcta y el indicador de mainnet/testnet
* Su cabecera contiene el número correcto de bloques de Stacks anteriores a este.
* Su cabecera contiene el total correcto de Bitcoin gastado en la sortición que eligió la tenencia actual.
* Su cabecera contiene el mismo hash de bloque de Bitcoin que el bloque de Bitcoin que contiene la transacción de block-commit de su tenencia\*
* Su cabecera contiene el ID correcto del bloque padre inmediato de este bloque.\*
* La raíz del árbol de Merkle de transacciones es coherente con las transacciones
* El hash de la raíz del estado coincide con el hash de la raíz de la punta de MARF una vez aplicadas todas las transacciones
* La cabecera del bloque tiene una firma ECDSA válida del minero.
* La cabecera 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 el bloque de Bitcoin del block-commit de esta tenencia, sin incluirlo, se han aplicado al estado de la cadena de 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, en conjunto, la forma en que Stacks garantiza la finalidad de Bitcoin. Al adherirse a estas propiedades, se asegura de que los mineros solo puedan añadir bloques si construyen sobre la punta correcta de la cadena, lo que también ancla el historial a Bitcoin.
Los firmantes, al validar estas reglas, garantizan la finalidad 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 explica en la sección de minería, los mineros enviarán una `block-commit` transacción en la cadena de Bitcoin para iniciar la minería. Si son seleccionados, los Stackers detectarán eso y crearán una `tenure-change` 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 ocurrir que la tenencia de este minero se extienda a sorticiones posteriores; si esto sucede, entonces este `hash de consenso` valor permanece igual que 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 quema | Hash de consenso actual en la burnchain subyacente. Corresponde a la última sortición observada. | 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 la sortición. | 4 bytes, orden big-endian |
| causa | Un indicador para señalar la causa de este cambio de tenencia
- 0x00 indica que ocurrió una sortición y que 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 reinicia al procesar esta transacción.
| 1 byte |
| hash de la clave pública | 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 este debe incluirla como la primera transacción en su primer bloque; de lo contrario, los Stackers no la aprobarán.
Luego, 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](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md) para obtener una descripción detallada de exactamente lo que ocurre bajo el capó durante estos procesos.
A continuación, profundicemos un poco más en esta idea de la finalidad de Bitcoin y en cómo el mecanismo de producción de bloques de Stacks la logra.
***
### Recursos adicionales
* \[[StacksDevs YT](https://youtu.be/5F73LQXf3eg?si=t7VmBp0VJp6h2VEa)] Taller de firmantes del lanzamiento Nakamoto de Stacks
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.stacks.co/learn/es/block-production/signing.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.