Límite de sigops por bloque

Verificar firmas le cuesta tiempo a un nodo, así que el consenso mide ese trabajo con un presupuesto propio en lugar de imputarlo al espacio de bloque. BIP141 estableció el contador en 80.000 unidades y asignó a cada operación de firma heredada (legacy) un precio de cuatro de ellas, con lo que cuadruplicó un techo anterior de 20.000. Un retiro normal de una sola clave o Taproot gasta un puñado de unidades, así que el techo es invisible para casi todos los que mueven monedas.

Cómo funciona

El límite de sigops por bloque es un total acumulado, que se va sumando transacción a transacción a medida que un nodo conecta un bloque, y un bloque cuyo total supera 80.000 es inválido.

No se ejecuta nada para obtenerlo: un nodo escanea los bytes de los scripts y cuenta los opcodes (códigos de operación), así que una verificación de firma en una rama que el gasto nunca toma se imputa completa. El pesimismo es deliberado: un nodo tiene que saber que puede permitirse un bloque antes de verificar nada.

Se suman tres recuentos, y no todos recaen en la misma transacción. El recuento heredado lee los scripts de desbloqueo y los scripts de bloqueo de la propia transacción, multiplicados por cuatro, así que una operación escrita en un campo scriptPubKey se imputa a quien crea la salida y no a quien la gasta después. El recuento "pay to script hash" lee el script de canje revelado por la entrada que gasta, también multiplicado por cuatro. El recuento de testigo cuenta por su valor nominal: una unidad por una entrada P2WPKH, y un script P2WSH imputado exactamente como lo habría sido con P2SH.

Una diferencia entre esos escaneos cuesta dinero real. Las lecturas de P2SH y de testigo aplican el descuento de BIP141, por el que el opcode OP_CHECKMULTISIG precedido de OP_1 a OP_16 cuenta como entre una y dieciséis operaciones en lugar de las veinte fijas; el escaneo heredado nunca lo aplica. A una salida multisig simple de dos de tres se le imputan las veinte operaciones completas, ochenta unidades de presupuesto, y se le imputan al crearla.

El tapscript quedó fuera del presupuesto por completo. BIP342 excluyó las operaciones de firma de tapscript de las 80.000 unidades del bloque entero y dio a cada script su propia asignación: 50 unidades, más el tamaño serializado del testigo de esa entrada, asignación que disminuye en 50 cada vez que se ejecuta un opcode de firma con una firma real adjunta. Cincuenta sale de dividir cuatro millones de unidades de peso entre ochenta mil sigops, la proporción entre los dos techos.

Dónde aparece

La política de retransmisión se encuentra con el límite de sigops por bloque mucho antes que el consenso, a través de tres constantes de Bitcoin Core más estrictas que la regla de la red.

Una sola transacción no puede reclamar más de una quinta parte del presupuesto del bloque, 16.000 unidades. Una entrada "pay to script hash" estándar puede revelar un script de canje con un máximo de 15 operaciones de firma. Un tercer recuento lee las operaciones que no son de testigo allí donde realmente pueden ejecutarse y no donde se encuentran, e impide la retransmisión por encima de 2.500 por transacción; lee el scriptPubKey que se gasta, que el recuento de todo el bloque ya imputó al crearse la salida.

El límite también llega a su comisión. La opción bytespersigop de Bitcoin Core, con 20 como valor predeterminado, reemplaza el peso de una transacción por el mayor de dos valores, su peso real o su costo en sigops multiplicado por veinte, así que una transacción cargada de operaciones de firma para su tamaño se cobra como si fuera más grande de lo que es. Crear una salida multisig simple es la forma habitual de toparse con ella.

Los mineros se encuentran con el presupuesto como una segunda restricción junto al peso de bloque, algo que BIP342 da como motivo para excluir el tapscript: dos techos hacen más difícil construir un bloque que uno solo. Core reserva 400 unidades para las salidas coinbase antes de llenar una plantilla.

Límite de sigops por bloque frente a peso de bloque

El peso de bloque cuenta datos y el límite de sigops por bloque cuenta trabajo de verificación, y un bloque está lleno en cuanto alcanza cualquiera de los dos techos. El peso de bloque es el techo que un bloque ordinario alcanza primero, porque una entrada P2WPKH cuesta una unidad y un gasto Taproot no añade nada en absoluto, así que el límite de sigops por bloque solo decide el resultado en un bloque cargado de scripts de estilo antiguo. Si se divide un techo entre el otro, se obtienen 50 unidades de peso por operación de firma, la proporción que BIP342 reutilizó para poner precio al presupuesto de tapscript y lo más parecido que tiene el protocolo a un tipo de cambio entre bytes y verificaciones de firma.