Cómo funcionan las transacciones

Introducción

Las transacciones son la unidad fundamental de ejecución en Stacks. Cada transacción se origina desde una cuenta de Stacks y se conserva en la historia de la red Stacks para la eternidad. Esta guía te ayuda a entender las transacciones de Stacks.

Ciclo de vida

Las transacciones pasan por fases antes de ser finalmente confirmadas.

1

Generar

Las transacciones se ensamblan según la especificación de codificación.

2

Validar y firmar

Las transacciones se validan para confirmar que tienen una estructura correcta. Las firmas requeridas se completan.

3

Difundir

Las transacciones se envían a un nodo.

4

Registrar

Un minero recibe transacciones, las verifica y las añade al mempool, un área de retención para todas las transacciones pendientes.

5

Procesar

Los mineros revisan el mempool y seleccionan transacciones para el siguiente bloque que se va a minar. Dependiendo del tipo de transacción, pueden ocurrir distintas acciones durante este paso. Por ejemplo, se podrían verificar las postcondiciones de una transferencia de tokens, acuñar tokens definidos por un contrato inteligente, o intentar llamar a un método de un contrato inteligente existente.

6

Confirmar

Los mineros proponen con éxito bloques con un conjunto de transacciones. Las transacciones contenidas se propagan correctamente a la red cuando los stackers las aprueban.

Una transacción puede tener uno de tres estados una vez que se registra: pendiente, éxito, o fallida.

Tipos

Stacks admite un conjunto de diferentes tipos de transacciones:

Tipo	Valor	Descripción
Cambio de tenure	TenureChange	Un cambio de tenure es un evento en la cadena de bloques de Stacks existente cuando un minero asume la responsabilidad de crear nuevos bloques de Stacks desde otro minero. Un cambio de tenure ocurre cuando se descubre un bloque de Stacks a partir de una sortición criptográfica. Realizado por stackers.
Bloque de cambio de tenure encontrado	TenureChange-BlockFound	A TenureChange-BlockFound la transacción es inducida por una sortición ganadora. Esto hace que el nuevo minero empiece a producir bloques y detiene al minero actual de producir más bloques.
Extensión de cambio de tenure	TenureChange-Extend	A TenureChange-Extend, que es inducida por los Stackers, reinicia el presupuesto de ejecución en curso del tenure actual, permitiendo así que el minero continúe produciendo bloques.
Transferencia de tokens	token_transfer	Transferencia de activos de un remitente a un destinatario
Despliegue de contrato	smart_contract	Instanciación del contrato
Llamada al contrato	contract_call	Llamada al contrato para una función pública que no es de solo lectura

Comisiones

Las comisiones se utilizan para incentivar a los mineros a confirmar transacciones en la cadena de bloques de Stacks. La comisión se calcula en función de la tarifa de comisión estimada y del tamaño de la transacción en bruto en bytes. La tarifa de comisión es una variable determinada por el mercado. Para la testnet, se establece en 1 micro-STX.

Nonces

Cada cuenta tiene una propiedad nonce que indica el número de transacciones procesadas para la cuenta dada. Los nonces son códigos de un solo uso, que comienzan en 0 para las cuentas nuevas y se incrementan en 1 en cada transacción.

Los nonces se añaden a todas las transacciones y ayudan a identificarlas en orden para garantizar que las transacciones se procesen en secuencia y evitar el procesamiento duplicado.

El mecanismo de consenso también garantiza que las transacciones no se "reproduzcan" de dos maneras. Primero, los nodos consultan sus salidas de transacciones no gastadas (UTXOs) para satisfacer sus condiciones de gasto en una nueva transacción. Segundo, los mensajes enviados entre nodos revisan los números de secuencia.

Cuando se construye una nueva transacción de transferencia de tokens, se necesita obtener y establecer el nonce más reciente de la cuenta.

Cómo se detectan y resuelven los huecos de nonce

Las transacciones de Stacks deben ejecutarse estrictamente en orden de nonce. Cuando se envía una transacción con un nonce superior al esperado, la red no la rechaza de inmediato; en su lugar, rastrea el hueco y espera a que lleguen los nonces que faltan.

A continuación se muestra un recorrido conceptual, con respuestas visuales de la API, de cómo se comporta el sistema cuando los nonces se envían fuera de orden.

1

Estado inicial (sin transacciones pendientes)

{
  last_mempool_tx_nonce: null,
  last_executed_tx_nonce: 241,
  possible_next_nonce: 242,
  detected_missing_nonces: [],
  detected_mempool_nonces: []
}

Interpretación

• Todas las transacciones hasta el nonce 241 se han ejecutado

• La red espera el nonce 242 siguiente

• No hay transacciones esperando actualmente en el mempool

• No existen huecos de nonce

2

Envío de un nonce futuro (245)

{
  last_mempool_tx_nonce: 245,
  last_executed_tx_nonce: 241,
  possible_next_nonce: 246,
  detected_missing_nonces: [244, 243, 242],
  detected_mempool_nonces: []
}

Interpretación

• Una transacción con nonce 245 ahora está en el mempool

• Nonces 242, 243, y 244 faltan

• La ejecución no puede continuar hasta que se envíen esos nonces

• possible_next_nonce refleja el nonce más alto observado + 1

3

Envío de un hueco parcial (243)

{
  last_mempool_tx_nonce: 245,
  last_executed_tx_nonce: 241,
  possible_next_nonce: 246,
  detected_missing_nonces: [244, 242],
  detected_mempool_nonces: [243]
}

Interpretación

• Nonce 243 ahora está presente en el mempool

• Nonces 242 y 244 siguen faltando

• La ejecución sigue bloqueada

• La API distingue entre:

  • detected_mempool_nonces → presentes pero no ejecutados

  • detected_missing_nonces → requeridos pero aún no vistos

4

Rellenando más huecos (244)

{
  last_mempool_tx_nonce: 245,
  last_executed_tx_nonce: 241,
  possible_next_nonce: 246,
  detected_missing_nonces: [242],
  detected_mempool_nonces: [243, 244]
}

Interpretación

• Nonces 243 y 244 están ambos esperando en el mempool

• Nonce 242 sigue faltando

• La ejecución permanece en pausa en 241

5

Todos los nonces requeridos presentes (242)

{
  last_mempool_tx_nonce: 245,
  last_executed_tx_nonce: 241,
  possible_next_nonce: 246,
  detected_missing_nonces: [],
  detected_mempool_nonces: [242, 243, 244]
}

Interpretación

• Todos los nonces requeridos (242–245) ya están disponibles

• No quedan huecos

• La red puede ejecutar transacciones secuencialmente

6

Después de que la ejecución se completa

{
  last_mempool_tx_nonce: null,
  last_executed_tx_nonce: 245,
  possible_next_nonce: 246,
  detected_missing_nonces: [],
  detected_mempool_nonces: []
}

Interpretación

• Todas las transacciones pendientes se han ejecutado

• El nonce de la cuenta ha avanzado a 245

• El siguiente nonce válido ahora es 246

• El estado del mempool vuelve a estar limpio