Firma: verificación de la validez de bloques
Cómo los firmantes validan y firman 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 tenencia.
Recursos para constructores
Para operar como firmante, vea Ejecutar un firmante.
Para ver una lista completa de firmantes activos, consulte la página de firmantes del Explorer.
La visión general
Los firmantes validan y firman los bloques propuestos de Stacks antes de que puedan unirse a la cadena.
El conjunto de firmantes se fija en cada ciclo de recompensa: todo signer-manager con al menos 50,000 STX apostados en él.
El peso de voto de un firmante es proporcional a los STX apostados 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 Stacks que anteriormente 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 se destinó a separar estas dos preocupaciones manteniendo tanto la minería como el staking de membresía abierta. Cualquiera puede convertirse en minero y cualquiera puede convertirse en staker. SIP-021 describe el diseño tal como se introdujo.
Los firmantes deben reconocer y validar 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 sobre 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 peer 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 desactualizada, los firmantes se niegan a firmarlo. Si los firmantes no pueden ponerse de acuerdo sobre la punta canónica de Stacks, en primer lugar no se añade ningún bloque. El modo de fallo que esto crea, una cadena que se detiene mientras los firmantes discrepan, se mitiga manteniendo el conjunto de firmantes lo suficientemente grande y diverso como para que siempre se alcance quórum, y pagando a los firmantes mediante recompensas PoX para que permanezcan en línea.
Cómo se seleccionan los firmantes
Bajo PoX-5, un firmante es un 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 grant que nombra al administrador, y el administrador lo envía mediante grant-signer-key y se registra con register-signer. El titular de la clave puede revocar el grant en cualquier momento con revoke-signer-grant, lo que impide que el administrador acepte nuevos stakes mientras las posiciones existentes se van liquidando.
Durante cada fase de preparación, los últimos 100 bloques de Bitcoin de un ciclo de recompensa, el conjunto de firmantes para el ciclo siguiente se fija: todo signer-manager registrado con al menos 50,000 STX (SIGNER_SET_MIN_USTX) apostados en él en total. El peso de voto de un firmante para ese ciclo es proporcional al total de STX apostados a través de él, contando juntos los STX en stakes solo de STX y la parte de STX de los bonos de protocolo. La parte BTC de un bono no tiene peso de firma: el peso de firma, como el peso de gobernanza, es una función solo de los STX bloqueados.
El software del firmante detecta a partir del estado de la cadena si su administrador está en el conjunto de firmantes del próximo ciclo. 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
Los stakers no son firmantes. La firma la realiza la clave concedida al signer-manager al que hacen staking, y ejecutar ese firmante es tarea del operador del administrador.
Cada firmante está respaldado por STX apostados. Para estar en el conjunto de firmantes, un administrador debe representar al menos el umbral agregado de 50,000 STX, 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 lo acepta solo cuando las firmas son válidas, no contienen duplicados, están ordenadas de forma coherente con el conjunto de firmantes, y en conjunto representan al menos el 70% del peso total de firmantes para el ciclo. El umbral es una constante de consenso en el nodo (NAKAMOTO_SIGNER_BLOCK_APPROVAL_THRESHOLD).
El peso, en este protocolo, es el stake: un signer-manager que representa el 10% de todos los STX apostados lleva el 10% del voto en cada bloque. Los bloques son aceptados por una mayoría económica del capital bloqueado, que es lo que vincula la producción de bloques con el staking descrito en la página de staking.
Validación y anexado de nuevos bloques
Cuando se selecciona a mineros para una nueva tenencia, 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 los firmantes para que se añada a la cadena.
Los firmantes aprueban un bloque en función de varias propiedades:
El bloque está bien formado
Tiene la versión correcta y la bandera de 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 gastado en la sortition 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 correcto del bloque padre del 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
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 esta tenencia 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
TenureChangetransacción.La primera transacción después de la
TenureChangetransacción es unaCoinbase.
Las propiedades marcadas con * son, en conjunto, la forma en que Stacks garantiza la finalidad de Bitcoin. Al adherirse a ellas, los mineros solo pueden añadir bloques que se construyan sobre la punta correcta de la cadena, lo que también ancla la historia a Bitcoin.
Realización de cambios de tenencia de minero
La otra responsabilidad principal de firma en la producción de bloques es realizar transacciones de cambio de tenencia. Como se discutió en la sección de minería, los mineros envían una block-commit transacción en la cadena de Bitcoin para iniciar la minería. Si se selecciona a un minero, los firmantes detectan eso y crean una tenure-change transacción.
Esta transacción de cambio de tenencia incluye:
hash de consenso de la tenencia
Hash de consenso de esta tenencia. Corresponde a la sortition en la que se eligió al minero de este bloque. Puede ocurrir que la tenencia de este minero se extienda a 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 de la tenencia anterior
Hash de consenso de la tenencia anterior. Corresponde a la sortition del block-commit ganador anterior.
20 bytes
hash de consenso de la burn view
Hash de consenso actual en la burnchain subyacente. Corresponde a la sortition vista más recientemente.
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 sortition.
4 bytes, big-endian
causa
Un indicador para señalar la causa de este cambio de tenencia\n- 0x00 indica que ocurrió una sortition y que un nuevo minero debe comenzar a producir bloques.\n- 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 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 luego 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 las tenencias.
SIP-021 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 un grant único, revocable por el titular de la clave.
Los reward slots ya no existen, y con ellos el límite de 4,000 slots por ciclo. El conjunto de firmantes es el conjunto de signer-managers que califican, y el peso proviene de los STX apostados en lugar de los slots conseguidos.
La delegación ya no existe, así 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 Schnorr agregada generada mediante el protocolo WSTS, incluida una ronda de generación distribuida de claves en cada ciclo. El nodo valida los bloques frente a un conjunto de firmas individuales de firmantes ponderadas por stake, como se describió arriba. Lea el material de WSTS en SIP-021 como historia del diseño.
Recursos adicionales
Última actualización
¿Te fue útil?