Firma

Los Stackers desempeñan un papel esencial en el sistema Nakamoto que antes había sido responsabilidad de los mineros. Antes, los mineros decidían tanto el contenido de los bloques como si incluirlos o no 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 fiable sin bifurcaciones:

• Miners deciden el contenido de los bloques.

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

La mayor parte de la complejidad de los cambios de Nakamoto radica en separar estas dos preocupaciones asegurando al mismo tiempo 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, 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 están obligados a 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 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 punto los nodos añaden el bloque a sus historiales de la 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 ningún bloque será añadido 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 de Stackers grande y diverso 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 de esa manera.

Firma de Stackers

Puedes ver una lista de todos los firmantes activos en el explorador de bloques de Stacks.

Cubriremos cómo funciona el stacking en la sección de Stacking y la firma sBTC en la sección sBTC; aquí trataremos el proceso de firma en lo que se refiere a la producción de bloques de Stacks.

El medio por el cual los Stackers acuerdan la punta canónica de la cadena y aceptan 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 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 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 llega a conocer 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 el X% de los espacios de recompensa están representados 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 usa 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 añadidura de nuevos bloques

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

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

• El bloque está bien formado

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

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

  • Su cabecera contiene el total correcto de Bitcoin gastados 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 compromiso de bloque de su tenencia*

  • Su cabecera 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

  • La raíz del estado coincide con la raíz MARF tip 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 (pero sin incluir) el bloque de Bitcoin del compromiso de bloque 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 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 la manera en que Stacks asegura la finalización de Bitcoin. Al adherirse a estas propiedades, se asegura 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 Stackers, al validar estas reglas, aseguran la finalización de Bitcoin. Hablaremos más sobre esto en la siguiente sección.

Realización de cambios de tenencia de minero

La otra responsabilidad principal de firma en la producción de bloques implica realizar 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 un 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 subsecuentes; 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 previa	Hash de consenso de la tenencia previa. 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 previa	El hash del bloque índice del último bloque de Stacks de la tenencia anterior.	32 bytes
bloques de la tenencia previa	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 elegido y deben 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 conforme se eligen nuevos mineros para las tenencias.

Asegúrate de echar un vistazo a SIP-021 para obtener una descripción detallada de exactamente qué sucede 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 consigue.