Reglas de consenso y validación

Curiosidad

1. ¿Qué impide que un minero con la mayor potencia imprima monedas infinitas?
2. ¿Por qué una transacción que tu nodo se niega a retransmitir puede terminar en un bloque válido?
3. Si cambia el código de consenso, ¿tienen que actualizar todos al mismo instante?

Explorar

1. Las reglas de consenso son los criterios estrictos que cada nodo completo utiliza para validar bloques. Definen lo que es técnicamente posible: el calendario de emisión, el límite de peso del bloque de 4.000.000 de unidades, la dificultad del proof-of-work y la validez de las firmas. Un bloque que incumpla cualquiera de estas reglas es rechazado por todos los nodos honestos, independientemente de cuánta potencia de hash haya generado. Los mineros proponen bloques; los nodos deciden si se contabilizan o no. Esta separación garantiza que ninguna entidad pueda alterar unilateralmente el estado del registro.
2. Las reglas de política determinan qué información un nodo retransmite a sus pares antes de minar. Incluyen umbrales de “dust”, tarifas mínimas de retransmisión y tipos estándar de scripts. La mayoría de los nodos descartan las transacciones que violan estas políticas, pero siguen siendo válidas si un minero las incluye en un bloque. Esta distinción es importante: confiar en el rechazo basado en las políticas para garantizar la seguridad es arriesgado, ya que un actor decidido puede sortear los filtros de los pares y enviar directamente las transacciones a los mineros, obligando a la red a aceptar transacciones no estándar siempre y cuando cumplan con el consenso.
3. El código es la especificación. Las reglas son aquellas que aplica realmente el software de nodos más utilizado, incluidos los casos límite; por eso los cambios en el código relacionado con el consenso se realizan lentamente y se revisan con mayor intensidad que cualquier otro elemento en Bitcoin Core. Los errores relacionados con el consenso se tratan como emergencias: el error de desbordamiento de valores en 2010 y el error de inflación en 2018 fueron corregidos bajo presión, mediante lanzamientos coordinados.
4. Los cambios en estas reglas requieren una adopción coordinada. Los soft forks endurecen las reglas, por lo que los nodos no actualizados siguen aceptando los nuevos bloques; los hard forks las relajan o modifican, por lo que todos los nodos deben actualizarse o separarse. Una lección posterior tratará ambos aspectos en detalle. SegWit (agosto de 2017) fue un soft fork; Bitcoin Cash (agosto de 2017) surgió a raíz de una disputa sobre los límites de tamaño del bloque que derivó en un hard fork.
5. Producir un bloque es caro; verificar uno es barato. Un minero que produce un bloque inválido pierde la recompensa y la energía gastada, ya que todos los nodos de validación lo descartarán, lo que convierte el incumplimiento de las reglas en una apuesta costosa. Este costo refuerza la rigurosidad de la validación: la seguridad de la red depende de miles de nodos independientes que verifican cada encabezado y transacción, asegurando así que ningún punto único de fallo pueda corromper el estado compartido.
6. Abra un explorador de bloques como mempool.space o blockchain.com. Seleccione cualquier bloque reciente y examine su campo de “peso”. Compare este número con el límite de 4,000,000 unidades de peso definido en BIP141. Observe cuán cerca están los bloques modernos de este techo, lo que refleja que los mineros maximizan los ingresos por byte al mismo tiempo que se mantienen dentro de las restricciones del consenso impuestas por cada nodo.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 12
• E. Lombrozo, J. Lau & P. Wuille, BIP141: Segregated Witness (Consensus layer) (2015)
• Bitcoin Core source code: validation.cpp and policy.cpp
• Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, section 5