115 / 736NC

Nakamoto Consensus

Cómo acuerda Bitcoin la historia de los pagos

Bitcoin no tiene un contable central. Construye una historia compartida mediante la verificación independiente, la minería y la elección de la cadena válida con más trabajo acumulado.

Nakamoto Consensus designa la forma en que Bitcoin alcanza una historia válida y compartida de las transacciones sin un árbitro central. Un Full Node, un ordenador con software que verifica las reglas, descarta primero los bloques inválidos. Entre las ramas válidas elige después la de mayor trabajo acumulado. Más confirmaciones aumentan la confianza en un pago bajo ciertas condiciones de seguridad; no lo vuelven irreversible de inmediato.

Anna envía un pago a Pedro. También podría firmar otra transacción que gastase esos mismos fondos a favor de Eva. Firmar significa aquí usar una clave privada, un valor numérico secreto, para crear una prueba verificable de autorización del pago. Los demás pueden comprobar la firma sin conocer ese secreto. Ambas firmas podrían ser auténticas, pero los dos pagos no caben en una misma historia válida. Además, Pedro y Eva podrían recibir los mensajes en distinto orden. Bitcoin necesita, por tanto, algo más que verificar firmas: una forma de acordar el orden e impedir el doble gasto. Nakamoto Consensus combina reglas, Proof of Work, elección de rama y recompensas a los mineros. El whitepaper de Satoshi, la descripción técnica original de Bitcoin, no utiliza este nombre posterior. [1] [4]

El Full Node de Pedro no es una papeleta de voto. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Una salida de transacción registra una cantidad y las condiciones para gastarla después. El software del Full Node comprueba por sí mismo transacciones y bloques: si las salidas que se gastan siguen sin gastar, si se cumplen sus condiciones de gasto y si no se crean más bitcoins de los permitidos. Un minero puede proponer un bloque, pero no saltarse estas comprobaciones. Un bloque inválido sigue siéndolo aunque lo respalde un trabajo enorme. Solo se comparan ramas válidas; compartir una historia exige reglas compatibles entre los participantes. [2] [3]

Si cada ordenador conectado tuviera un voto, un atacante podría crear muchos participantes aparentemente independientes. Eso es un Sybil Attack. En lugar de contar nombres, Proof of Work vincula el peso de una rama al trabajo computacional demostrable. Los mineros calculan repetidamente hashes, huellas digitales de datos, hasta obtener un resultado que cumpla una condición. Los intentos requieren energía y equipos, mientras que comprobar el resultado es fácil. Muchas identidades de red no añaden trabajo por sí solas: no se verifican documentos de identidad ni votan todos los nodos. [1] [4]

El minero prepara un bloque candidato y modifica su cabecera, un resumen compacto del bloque, hasta que su hash, interpretado como número, sea menor o igual al objetivo válido. No resuelve una ecuación útil ni rompe un cifrado: busca un resultado poco frecuente. Dos mineros pueden lograrlo casi simultáneamente. Una parte de la red ve primero un bloque y otra, el otro; aparecen brevemente dos ramas válidas. Eso no es por sí solo una avería. Si los bloques se propagan con normalidad, el trabajo posterior permite converger en la rama más fuerte. [1] [8]

La fuerza de una rama se mide mediante chainwork, la suma del trabajo asignado a cada bloque a partir de su objetivo. No es un contador eléctrico ni un registro de los intentos realmente realizados. Un minero puede tener suerte enseguida y otro tardar mucho; con el mismo objetivo, sus bloques válidos pesan lo mismo. Un Full Node elige la rama válida disponible con la suma mayor. Por eso, «cadena más larga» significa más trabajo, no necesariamente más bloques. Cambiar de rama es una reorganización; un pago del bloque abandonado puede incluirse de nuevo si sigue siendo válido. [1] [2] [3] [7]

Cuando el pago de Anna entra en un bloque aceptado, tiene una confirmación. Cada bloque posterior añade otra. Para sustituir esa historia, una rama competidora tendría que alcanzar su trabajo. Suponiendo una mayoría honesta de potencia de cálculo y una propagación suficientemente rápida, el riesgo de reescritura suele disminuir con la profundidad. Eso es finalidad probabilística: confianza creciente, no imposibilidad matemática de cambiar. Las confirmaciones que Pedro exige también dependen del valor del pago y del riesgo. Ningún número universal garantiza seguridad en cualquier circunstancia. [1] [4]

Si la condición no cambiara al llegar máquinas más rápidas, los bloques aparecerían antes. Por eso, Difficulty Adjustment recalcula el objetivo de la red principal cada 2016 bloques, usando marcas de tiempo anteriores. Busca una media de diez minutos por bloque, aproximadamente dos semanas para ese tramo. Un bloque concreto puede llegar mucho antes o después. El ajuste depende del número de bloques, no de una fecha del calendario: si desaparece mucha potencia de golpe, alcanzar el siguiente ajuste puede tardar más. No es un regulador instantáneo ni un reloj exacto. [2] [8]

Los bitcoins recién emitidos, la subvención de bloque, y las comisiones remuneran a los mineros por bloques que permanecen en la historia aceptada. Esto incentiva a ampliarla, pero no sustituye las condiciones de seguridad. Una mayoría de potencia puede reorganizar ramas válidas, omitir pagos e intentar revertir gastos propios. No puede obligar a un Full Node a aceptar firmas inválidas, emisión excesiva ni gastos ajenos sin autorización. El umbral del 50% tampoco es un interruptor de seguridad: algunos ataques tienen posibilidades por debajo. Las recompensas no crean honestidad por sí solas. [1] [2] [3]

Volvamos a Pedro. Si un atacante controla todas las conexiones de su nodo, puede mostrarle una visión incompleta de lo que ocurre. Un Eclipse Attack consiste en ese aislamiento de red; las confirmaciones pueden entonces tener un significado distinto al que tienen con buena conectividad. Dividir la red en partes desconectadas también dificulta el acuerdo. La seguridad depende de la potencia atacante, de cómo circulan los mensajes y de la verificación honesta. La investigación Bitcoin Backbone modela expresamente estas condiciones. Un porcentaje de potencia sin condiciones de red no explica toda la seguridad. [4]

Los métodos BFT (Byzantine Fault Tolerance) clásicos, que buscan acuerdo incluso con participantes defectuosos o maliciosos, suelen partir de un grupo conocido. Ejemplos como OM (Oral Messages) y PBFT (Practical Byzantine Fault Tolerance) tienen sus propias condiciones y reglas de intercambio de mensajes. Bitcoin aborda la participación abierta mediante trabajo y una convergencia probabilística de la historia; no es simplemente otro nombre para esos métodos. Elegir una rama válida más fuerte tampoco cambia las reglas de validez. Cambiarlas requiere que los participantes adopten el software adecuado y condiciones compatibles. Los mineros ayudan a decidir qué historia válida continúa, no qué debe considerar válido todo el mundo. [5] [6] [9]

Para obtener la imagen más completa, lee esta entrada junto con Bitcoin, Proof of Work, Difficulty Adjustment, Reglas de consenso, Minería, Full Node. También enlazan con esta entrada Bit Gold, Reusable Proofs of Work, Byzantine Generals Problem, Sybil Attack.

DOC · 001Satoshi Nakamoto — Bitcoin: A Peer-to-Peer Electronic Cash SystemFuente primaria DOC · 002Bitcoin Developer Guide — Block ChainDocumentación DOC · 003Bitcoin Core v29.0 — Chainstate validationDocumentación DOC · 004The Bitcoin Backbone ProtocolFuente primaria DOC · 005The Byzantine Generals ProblemFuente primaria DOC · 006Bitcoin Optech — Soft fork activationFuente primaria DOC · 007Bitcoin Core v29.0 — Block proof and chainworkFuente primaria DOC · 008Bitcoin Core v29.0 — Proof of Work and retargetingFuente primaria DOC · 009Castro & Liskov — Practical Byzantine Fault Tolerance (1999)Fuente primaria
Revisado: Fuentes primero · No es asesoramiento financiero