# Especificaciones técnicas

### Consenso

* Prueba de transferencia (PoX) como se describe en [SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md)
* La red pasará a Prueba de quema (PoB) como se describe en [SIP-001](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md) después de 10 años. [Obtenga más información sobre Proof-of-Burn en SIP-001](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md).
* Modelo de amenazas
  * El 51 % del poder de minado malicioso de Bitcoin puede reorganizar la cadena de Stacks o llevar a cabo un ataque de doble gasto
  * La cadena puede detenerse si los Stackers no pueden alcanzar un consenso del 70 % sobre la validez de los bloques
* Distintos actores y sus roles
  * Los mineros de Stacks empaquetan las transacciones en bloques y se las proponen a los stackers
  * Los titulares de Stacks pueden modificar el cálculo de los límites de bloque (sujeto a veto del minero) y pueden votar para deshabilitar las recompensas de Proof-of-Transfer durante un ciclo de recompensas.
  * Los stackers validan y añaden bloques a la cadena y validan las transacciones de depósito y retiro de sBTC

### Minería de Proof of Transfer

* Calendario de recompensas de coinbase:
  * 1000 STX/bloque durante los primeros 4 años
  * 500 STX/bloque durante los siguientes 4 años
  * 250 STX/bloque durante los 4 años posteriores
  * 125 STX/bloque de forma perpetua a partir de entonces
* Las recompensas de coinbase se acumulan por «sortitions perdidos»: si un bloque de Bitcoin no tiene sortition (en la altura N), entonces cualquier bloque de Stacks minado en un sortition posterior que se construya sobre cualquier punta de la cadena de Stacks que existiera en el penúltimo sortition (en la altura N-1) puede reclamar su coinbase. Esto incentiva a los mineros a seguir minando incluso si las comisiones de Bitcoin son altas.
* Bonificación inicial de minería: este es un caso especial de lo anterior para incentivar a los primeros mineros. La coinbase de todos los bloques de la burnchain entre la primera altura de bloque de quema (que será elegida por mineros independientes como parte del lanzamiento de Stacks 2.0) y el primer ganador de sortition se acumula y se distribuye a los mineros durante una ventana fija (por determinar). Por ejemplo, supongamos que la altura del bloque de quema es 10.000 y el primer sortition ocurre en el bloque 10500 y la ventana de distribución es de 100 bloques; entonces la coinbase de los primeros 500 bloques (10.500 - 10.000) se distribuirá equitativamente entre los mineros que ganen sortition durante los 100 bloques posteriores.
* Ventana de maduración de recompensas: 100 bloques, lo que significa que los líderes obtendrán la recompensa de coinbase 100 bloques después del bloque que minen con éxito.
* Intervalo de bloque: la cadena de bloques de Stacks produce bloques rápidos aproximadamente cada 10 segundos, con un cambio de tenencia de minero en cada bloque de Bitcoin
* Compromiso BTC: los mineros deben comprometer al menos 11.000 satoshis (5.500 sats / [salida UTXO](https://learnmeabitcoin.com/technical/utxo)); 2 salidas / bloque) para evitar el «dust».
* Para más detalles, consulte Producción de bloques.

### Stacking

{% stepper %}
{% step %}
**Fase de preparación**

Se elige un «bloque ancla». El conjunto de direcciones que cumplen los requisitos («conjunto de recompensas») se determina a partir de la instantánea de la cadena en el bloque ancla. La duración de la fase de preparación es de 100 bloques. Los compromisos de stacking deben confirmarse antes de que comience esta fase.
{% endstep %}

{% step %}
**Fase de recompensas**

Los compromisos BTC de los mineros se distribuyen entre el conjunto de recompensas. La duración del ciclo de recompensas es de 2000 bloques de BTC (\~2 semanas).
{% endstep %}
{% endstepper %}

* Dos direcciones de recompensa por bloque, para un total de 4000 direcciones en cada ciclo de recompensas. Las direcciones se eligen mediante una VRF (función aleatoria verificable), de modo que cada nodo pueda llegar de forma determinista a las mismas direcciones de recompensa para un bloque dado.
* Umbral de stacking: 0,025 % del monto participante de STX cuando la participación está entre el 25 % y el 100 % y, cuando la participación es inferior al 25 %, el nivel de umbral siempre es 0,00625 de la oferta líquida de STX.
* Delegación: una dirección STX puede designar otra dirección para participar en Stacking en su nombre. [Sección relevante en SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md#stacker-delegation).
* Agrupación: los titulares de STX que individualmente no alcanzan el umbral de Stacking pueden unir sus participaciones para participar en Stacking. Para ello, los titulares de STX deben establecer la dirección de recompensa (opcional) como la «dirección delegada». Para más detalles, consulte [esta referencia](https://docs.stacks.co/references/stacking-contract#delegate-stx).
* Se admiten direcciones Legacy, SegWit, Native SegWit y Taproot

### Cuentas y direcciones

* Las transacciones en la cadena de bloques de Stacks se originan, son pagadas y se ejecutan bajo la autoridad de cuentas
* Una cuenta se especifica completamente por su dirección + nonce + activos
* La dirección contiene 2 o 3 campos: versión de 1 byte, hash de clave pública de 20 bytes (RIPEMD160(SHA256(input))), nombre opcional (longitud variable, máximo 128 bytes)
* Dos tipos de cuentas: las cuentas estándar son propiedad de una o más claves privadas; las cuentas de contrato se materializan cuando se instancia un contrato inteligente (especificado por el campo de nombre opcional anterior)
* El nonce cuenta el número de veces que una cuenta ha autorizado una transacción. Comienza en 0; la autorización válida debe incluir el *siguiente* valor de nonce.
* Los activos son un mapa de todos los tipos de activos — STX, cualquier activo en cadena especificado por un contrato Clarity (por ejemplo, NFTs) — a las cantidades poseídas por esa cuenta.
* No es necesario que las cuentas sean «creadas» o registradas explícitamente; todas las cuentas existen implícitamente y se instancian en el primer uso.

### Transacciones

* Tipos de transacción: coinbase, token-transfer, contract-deploy, contract-call, tenure-change.
* Solo las cuentas estándar (no los contratos) pueden pagar tarifas de transacción.
* La ejecución de transacciones está regida por:

{% stepper %}
{% step %}
**Cuenta originadora**

La cuenta que crea, autoriza y envía la transacción.
{% endstep %}

{% step %}
**Cuenta pagadora**

La cuenta a la que el líder cobra el costo de validar y ejecutar la transacción.
{% endstep %}

{% step %}
**Cuenta emisora**

La cuenta que identifica quién está ejecutando actualmente la transacción: esto puede cambiar a medida que una transacción se ejecuta mediante la función `as-contract` de Clarity.
{% endstep %}
{% endstepper %}

* Las transacciones pueden agruparse o transmitirse a los bloques. El comportamiento puede controlarse mediante el modo de anclaje de una transacción. Con la transmisión (microbloques), es posible un tiempo de confirmación más rápido.
* Dos tipos de autorizaciones: la autorización estándar es aquella en la que la cuenta originadora es la misma que la cuenta pagadora. *Patrocinada* la autorización es aquella en la que la cuenta originadora y la cuenta pagadora son distintas. Por ejemplo, los desarrolladores o proveedores de servicios podrían pagar para que los usuarios llamen a sus contratos inteligentes.
* Para la autorización patrocinada, primero un usuario firma con la cuenta originadora y luego un patrocinador firma con la cuenta pagadora.
* El límite del mempool para transacciones pendientes concurrentes es 25 por cuenta
* Las transacciones pendientes del mempool se recolectarán como basura [256 bloques después de la recepción](https://github.com/stacks-network/stacks-blockchain/blob/master/src/core/mempool.rs#L62). Con un tiempo objetivo de bloque de 10 minutos, esto equivaldría a \~42 horas
* [Obtenga más información sobre la codificación de transacciones en SIP-005](https://github.com/stacksgov/sips/blob/main/sips/sip-005/sip-005-blocks-and-transactions.md#transaction-encoding)
* [La firma y verificación de transacciones se describen en SIP-005](https://github.com/stacksgov/sips/blob/main/sips/sip-005/sip-005-blocks-and-transactions.md#transaction-signing-and-verifying)
* Todas las transacciones que afectan el saldo de una cuenta son atómicas; una operación de transferencia no puede incrementar el saldo de una cuenta sin decrementar el de otra. Sin embargo, las transacciones que realizan múltiples acciones de cuenta (por ejemplo, transferir desde varias cuentas) pueden completarse parcialmente.
* Las transacciones pueden incluir una cadena de memo (máx. 34 bytes)