Firma

Los Stackers desempeñan un papel esencial en el sistema Nakamoto que anteriormente había sido responsabilidad de los mineros. Antes, los mineros tanto decidían 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 forma fiable sin bifurcaciones:

• Mineros 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 consiste en separar estas dos preocupaciones a la vez que se asegura que tanto la minería como el Stacking sigan siendo procesos de membresía abierta. De forma crucial, 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 se requiere que los Stackers reconozcan y validen 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 cadena 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 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. Si bien este comportamiento crea un nuevo modo de fallo para Stacks —es decir, la cadena puede detenerse indefinidamente si los Stackers no se ponen de acuerdo sobre la punta— esto se mitiga al contar con 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 y al incentivarlos mediante recompensas PoX para que actúen como tal.

Firma por Stackers

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

Cubrirémos cómo funciona el stacking en la sección de Stacking y la firma de sBTC en la sección de sBTC; aquí trataremos el proceso de firma en lo que respecta a la producción de bloques de Stacks.

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 puestos de recompensa; hay como máximo 4.000 puestos de recompensa por ciclo de recompensas. 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 bloqueados 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 para que los nodos la usen 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 puestos 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. Es crucial que el protocolo de firma solo tendrá éxito si al menos X% de los puestos de recompensa están contemplados en la firma agregada. Nakamoto está configurado actualmente para usar un umbral de firma del 70 %: al menos el 70 % de los puestos de recompensa (por proxy, el 70 % de los STX apostados) 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, que admite un par de algoritmos de generación de clave distribuida y generación de firma 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 los mineros son seleccionados para un nuevo periodo, 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 anexen a la cadena.

Los Stackers aprobarán un bloque con base en varias propiedades:

• El bloque está bien formado

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

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

  • Su encabezado contiene el total correcto de Bitcoin gastados en la sortición que eligió el periodo 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 periodo*

  • 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 del tip MARF una vez que se aplican 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 este periodo se han aplicado al estado de la cadena de Stacks*

• En el caso de un bloque de inicio de periodo:

  • 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, en conjunto, la forma en que Stacks asegura la finalización en Bitcoin. Al adherirse a estas propiedades, se asegura que los mineros solo puedan anexar bloques si construyen sobre la punta de cadena correcta, lo que además ancla la historia a Bitcoin.

Los Stackers, al validar estas reglas, garantizan la finalización en Bitcoin. Hablaremos más sobre esto en la siguiente sección.

Realización de cambios de periodo de minero

La otra responsabilidad principal de firma en la producción de bloques implica realizar transacciones de cambio de periodo. 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 tenure-change .

Esta transacción de cambio de periodo incluye:

Nombre	Descripción	Representación
hash de consenso del periodo	Hash de consenso de este periodo. Corresponde a la sortición en la que se eligió al minero de este bloque. Puede darse el caso de que el periodo de este minero se extienda a través de sorticiones posteriores; 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 del periodo anterior	Hash de consenso del periodo 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 sortición vista por última vez.	20 bytes
fin del periodo anterior	El hash del bloque de índice del último bloque de Stacks del periodo anterior.	32 bytes
bloques del periodo anterior	El número de bloques producidos desde el último periodo vinculado a una sortición.	4 bytes, big-endian
causa	Una bandera para indicar la causa de este cambio de periodo - 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 del periodo del minero actual se reinicia al procesar esta transacción.	1 byte
hash de pubkey	El hash de la clave pública ECDSA del periodo actual.	20 bytes

Esta transacción de cambio de periodo 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 los periodos.

Asegúrate de echar un vistazo a SIP-021 para obtener una descripción detallada de exactamente lo que sucede bajo el capó durante estos procesos.

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