> For the complete documentation index, see [llms.txt](https://docs.stacks.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stacks.co/learn/es/block-production/signing.md).
# Firma: verificación de la validez de los bloques
Cómo los firmantes validan y firman los bloques de Stacks bajo PoX-5: cómo se elige el conjunto de firmantes en cada ciclo, qué es un bloque válido y cómo funcionan los cambios de tenure.
{% hint style="info" %}
**Recursos para constructores**
* Para operar como firmante, consulta [Ejecutar un firmante](https://docs.stacks.co/operate/run-a-signer).
* Para ver una lista completa de firmantes activos, consulta la [página de firmantes del Explorer](https://explorer.hiro.so/signers?chain=mainnet).
{% endhint %}
#### La visión general
* Los firmantes validan y firman los bloques de Stacks propuestos antes de que puedan unirse a la cadena.
* El conjunto de firmantes se fija en cada ciclo de recompensas. Cada signer-manager con al menos 50,000 STX apostados recibe una distribución de rendimiento.
* El peso de voto de un firmante es proporcional al STX apostado a través de él.
* Aceptar un bloque requiere firmas que representen al menos el 70 % del peso total de los firmantes.
* La firma evita bifurcaciones y ancla la historia de Stacks a Bitcoin.
***
### Introducción
Los firmantes desempeñan un papel en la red de Stacks que antes pertenecía a los mineros. Antes de la actualización Nakamoto, los mineros decidían tanto el contenido de los bloques como si los bloques se unían a la cadena. Desde Nakamoto, cada actor tiene una de esas responsabilidades:
* **Mineros** deciden el contenido de los bloques.
* **Firmantes** deciden si un bloque se incluye en la cadena.
La mayor parte de la complejidad en los cambios de Nakamoto consistió en separar estas dos preocupaciones manteniendo abiertos tanto la minería como el staking a la membresía abierta. Cualquiera puede convertirse en minero y cualquiera puede convertirse en staker. [SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) describe el diseño tal como se introdujo.
Se requiere que los firmantes reconozcan y validen el bloque de un minero antes de que pueda añadirse a la cadena. Para hacerlo, primero deben ponerse de acuerdo sobre la punta canónica de la cadena, y luego aplicar el bloque en esa punta para determinar su validez. Una vez que suficientes firmantes acuerdan que el bloque es canónico y válido, sus firmas acompañan al bloque a medida que se replica al resto de la red P2P de Stacks, y solo en ese momento los nodos lo añaden a sus historiales de cadena.
Este comportamiento evita bifurcaciones. Si un minero construye un bloque sobre una punta obsoleta, los firmantes se niegan a firmarlo. Si los firmantes no pueden ponerse de acuerdo sobre la punta canónica de Stacks, no se añade ningún bloque en primer lugar. El modo de fallo que esto crea, una cadena que se detiene mientras los firmantes discrepan, se mitiga manteniendo el conjunto de firmantes lo bastante grande y diverso como para que siempre se alcance el quórum, y pagando a los firmantes mediante recompensas de PoX para que permanezcan en línea.
***
### Cómo se seleccionan los firmantes
Bajo PoX-5, un firmante es un contrato signer-manager vinculado a una sola clave de firmante. El vínculo ocurre una sola vez: el titular de la clave de firmante firma un [SIP-018](https://github.com/stacksgov/sips/blob/main/sips/sip-018/sip-018-signed-structured-data.md) otorgamiento que nombra al gestor, y el gestor lo envía mediante `grant-signer-key` y se registra con `register-signer`. El titular de la clave puede revocar el otorgamiento con `revoke-signer-grant`, lo que hace que el gestor deje de aceptar nuevo stake mientras las posiciones existentes se van cerrando.
Durante cada fase de preparación, los últimos 100 bloques de Bitcoin de un ciclo de recompensas, el conjunto de firmantes para el ciclo siguiente queda fijado. Cada signer-manager registrado con al menos 50,000 STX (`SIGNER_SET_MIN_USTX`) apostados en total recibe una distribución de rendimiento. El peso de voto de un firmante para ese ciclo es proporcional al total de STX apostados a través de él, contando juntos el STX en apuestas solo de STX y la parte en STX de los bonos del protocolo. La parte en BTC de un bono no aporta peso de firma: el peso de firma, como el peso de gobernanza, es una función únicamente del STX bloqueado.
El software del firmante detecta a partir del estado de la cadena si su gestor está en el conjunto de firmantes del ciclo siguiente. Las transacciones de staking se envían manualmente; todo lo que el firmante hace con esa información es automático.
#### La relación entre stakers y firmantes
Manual por parte del staker, automático por parte del firmante
* Los stakers no son firmantes. La firma la realiza la clave otorgada al signer-manager al que hacen staking, y ejecutar ese firmante es trabajo del operador del gestor.
* Cada firmante está respaldado por STX apostados. Un gestor con al menos el umbral agregado de 50,000 STX recibe una distribución de rendimiento, y su peso crece con el stake que representa.
***
### Firma del firmante
Cuando un minero propone un bloque, cada firmante lo valida de forma independiente y lo firma con su clave de firmante concedida. El bloque lleva el conjunto resultante de firmas, y un nodo solo lo acepta cuando las firmas son válidas, no tienen duplicados, están ordenadas de forma coherente con el conjunto de firmantes y, en conjunto, representan al menos el 70 % del peso total de los firmantes para el ciclo. El umbral es una constante de consenso en el nodo ([`NAKAMOTO_SIGNER_BLOCK_APPROVAL_THRESHOLD`](https://github.com/stacks-network/stacks-core/blob/4.0.1/stackslib/src/core/mod.rs)).
El peso, en este protocolo, es stake: un signer-manager que represente el 10 % de todo el STX apostado lleva el 10 % del voto sobre cada bloque. Los bloques son aceptados por una mayoría económica del capital bloqueado, lo que vincula la producción de bloques con el staking descrito en la [página de staking](/learn/es/block-production/staking.md).
***
### Validación y anexado de nuevos bloques
Cuando se selecciona a los mineros para un nuevo mandato, comienzan a construir bloques a partir de transacciones en el mempool y los envían a los firmantes para su aprobación. Los firmantes deben aprobar un bloque con al menos el 70 % del peso de firmantes para que se añada a la cadena.
Los firmantes aprueban un bloque basándose en varias propiedades:
* El bloque está bien formado
* Tiene la versión correcta y el indicador de mainnet/testnet
* Su encabezado contiene el número correcto de bloques de Stacks anteriores a este.
* Su encabezado contiene el total correcto de Bitcoin gastado en la sortition que eligió el mandato actual.
* Su encabezado contiene el mismo hash del bloque de Bitcoin que el bloque de Bitcoin que contiene la transacción de block-commit de su mandato\*
* Su encabezado contiene el ID correcto del bloque padre inmediato de este bloque.\*
* La raíz del árbol de Merkle de las transacciones es coherente con las transacciones
* El hash raíz del estado coincide con el hash raíz de la punta de MARF una vez aplicadas todas las transacciones
* El encabezado del bloque tiene una firma ECDSA válida del minero.
* El encabezado del bloque lleva firmas de firmantes que cumplen el umbral de peso del 70 %.
* Todas las transacciones de Bitcoin desde la última sortition válida hasta (pero sin incluir) el bloque de Bitcoin del block-commit de este mandato se han aplicado al estado de la cadena de Stacks\*
* En el caso de un bloque de inicio de mandato:
* 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 atenerse a ellas, los mineros solo pueden añadir bloques que se construyen sobre la punta correcta de la cadena, lo que también ancla la historia a Bitcoin.
### Realización de cambios de mandato del minero
La otra responsabilidad principal de firma en la producción de bloques es realizar transacciones de cambio de mandato. Como se comentó en la sección de minería, los mineros envían una transacción `block-commit` en la cadena de Bitcoin para iniciar la minería. Si un minero es seleccionado, los firmantes lo detectan y crean una `tenure-change` transacción.
Esta transacción de cambio de mandato incluye:
| Nombre | Descripción | Representación |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- |
| hash de consenso del mandato | Hash de consenso de este mandato. Corresponde a la sortition en la que se eligió al minero de este bloque. Puede ocurrir que el mandato de este minero se prolongue a través de sortitions posteriores; si esto sucede, entonces este `hash de consenso` valor permanece igual que la sortition en la que se minó el block-commit ganador. | 20 bytes |
| hash de consenso del mandato anterior | Hash de consenso del mandato anterior. Corresponde a la sortition 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 sortition vista por última vez. | 20 bytes |
| fin del mandato anterior | El hash del bloque índice del último bloque de Stacks del mandato anterior. | 32 bytes |
| bloques del mandato anterior | El número de bloques producidos desde el último mandato vinculado a sortition. | 4 bytes, big-endian |
| causa |
Un indicador para señalar la causa de este cambio de mandato - 0x00 indica que ocurrió una sortition y que un nuevo minero debe comenzar a producir bloques. - 0x01 indica que el minero actual debe seguir produciendo bloques. El presupuesto de ejecución del mandato del minero actual se restablece al procesar esta transacción.
| 1 byte |
| hash de clave pública | El hash de la clave pública ECDSA del mandato actual. | 20 bytes |
Esta transacción de cambio de mandato se envía entonces al minero recién elegido, quien debe incluirla como la primera transacción en su primer bloque; de lo contrario, los firmantes no la aprobarán.
Este proceso se repite a medida que se eligen nuevos mineros para los mandatos.
[SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) tiene una descripción detallada de lo que sucede internamente durante estos procesos.
***
### Si conocías la firma bajo PoX-4
Las correcciones al modelo antiguo, en un solo lugar:
* Los stackers registraban una clave de firma de bloques con cada transacción de stacking o delegate-stack. Eso ya no existe: un signer-manager posee una clave de firmante mediante una concesión única, revocable por el titular de la clave.
* Han desaparecido los espacios de recompensa, y con ellos el límite de 4.000 espacios por ciclo. El conjunto de firmantes es el conjunto de signer-managers que califican, y el peso proviene del STX apostado en lugar de los espacios obtenidos.
* La delegación ya no existe, por lo que la antigua distinción entre stackers que firman y stackers que delegan su firma ya no describe nada. La firma pertenece a la clave concedida al signer-manager al que un staker hace staking.
* SIP-021 especifica la firma con una firma agregada de Schnorr generada mediante el protocolo WSTS, incluida una ronda de generación distribuida de claves en cada ciclo. El nodo valida bloques frente a un conjunto de firmas individuales de firmantes ponderadas por el stake, como se describió arriba. Lea el material de WSTS en SIP-021 como historia de diseño.
***
#### Recursos adicionales
* [SIP-021: Nakamoto](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md)
* [SIP-045: PoX-5, staking de Bitcoin](https://github.com/stacksgov/sips/blob/main/sips/sip-045/sip-045-pox-5-bitcoin-staking.md)
* [pox-5.clar en la versión 4.0.1](https://github.com/stacks-network/stacks-core/blob/4.0.1/stackslib/src/chainstate/stacks/boot/pox-5.clar)
* [Ejecutar un firmante](https://docs.stacks.co/operate/run-a-signer)
* [Generar una firma de firmante](https://docs.stacks.co/operate/staking-stx/generate-signer-signature)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.stacks.co/learn/es/block-production/signing.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
