¿Qué historial cuenta?
Los enlaces hash revelan cambios, pero no eligen un historial. Añadimos a DCoin una prueba de trabajo, distinguimos el trabajo acumulado del número de bloques y de los votos de los nodos, y seguimos una reorganización del conjunto de salidas. Después estudiamos emisión, comisiones y los supuestos de otros diseños de consenso.
Dos participantes de DCoin producen un bloque casi al mismo tiempo. Ambos extienden el mismo padre y contienen transacciones válidas. Un nodo recibe primero uno; otro, alejado, los recibe en orden contrario.
No hace falta que nadie esté atacando el sistema. La comunicación lleva tiempo y «el último bloque» es una observación local. Si DCoin elige simplemente el primero que llega, los nodos podrían mantener elecciones distintas indefinidamente.
La parte anterior nos dio una forma de validar una rama del historial. Ahora necesitamos compararlas y hacer costosa la reescritura de la elegida. Usaremos la prueba de trabajo como diseño principal y después compararemos los supuestos de otras alternativas.
3.1 Una bifurcación es un árbol, no dos registros independientes
Cada bloque tiene un padre. Los bloques conocidos por la red forman un árbol con raíz en el génesis. El registro activo corresponde a un camino de ese árbol. Otras ramas pueden seguir siendo conocidas sin aportar transacciones al estado activo.
Aquí las flechas muestran la extensión de padre a hijo, a diferencia de las referencias hash hacia atrás del artículo anterior. La relación subyacente es la misma.
Si pasa a preferirse otra rama, el nodo realiza una reorganización. Deshace los cambios de estado de la rama anterior hasta el ancestro común y aplica, en orden, los de la nueva. Una transacción eliminada del historial activo puede volver a quedar pendiente si sigue siendo válida y cumple la política de mempool del nodo. También puede resultar incompatible con una transacción de la nueva rama.
La terminología importa. Un bloque con padre conocido que pierde esta competición suele llamarse stale. Uno recibido antes de conocer a su padre suele llamarse huérfano. Algunas implementaciones y explicaciones antiguas usan estos términos de otra manera. Lo que necesitamos distinguir es una rama rival conocida de una dependencia que falta.
3.2 Exigir trabajo para proponer un bloque
Elegimos una función hash criptográfica con resultado de bits e interpretamos el resumen como un entero sin signo. Una cabecera candidata satisface la prueba de trabajo si
siendo el umbral que exige el protocolo en esa posición del historial. Un umbral menor deja menos hashes aceptables y exige, en promedio, más intentos.
El minero modifica repetidamente campos permitidos y calcula el hash de la cabecera resultante. El nonce aporta una fuente de variación; cambiar las transacciones modifica la raíz de Merkle y ofrece más posibilidades. Verificar es barato: basta con recalcular una vez el hash y comprobar el umbral. Encontrar un candidato adecuado es caro porque una buena función hash no ofrece un atajo práctico mejor que probar posibilidades.
Bajo el modelo idealizado habitual de hashes uniformes, la probabilidad de éxito de un intento es
El incluye el cero, que también es un resultado aceptable. Hacer más intentos por segundo aumenta la probabilidad de encontrar un bloque, pero no garantiza ganar en un intervalo concreto. Minar es una búsqueda probabilística, no una carrera por presentar el hash con más ceros iniciales al terminar un plazo fijo.
Podemos ilustrarlo con un espacio de hashes deliberadamente pequeño. Si y , hay 256 valores aceptables entre 65.536 posibles. El número esperado de intentos es 256. Eso no significa que cada intento número 256 tenga éxito: una búsqueda puede ser mucho más corta o mucho más larga.
3.3 Preferir el trabajo acumulado, no contar participantes
Si crear identidades de nodos es barato, contar sus votos permite inventar una mayoría con el mismo coste reducido. La prueba de trabajo pondera los historiales por la dificultad computacional que representan sus bloques.
Para un umbral al estilo de Bitcoin, la aportación de trabajo de un bloque puede expresarse como
La puntuación de una rama es la suma de esas aportaciones. Un nodo prefiere el historial válido con más trabajo acumulado. Si todos los bloques comparados tienen el mismo umbral, más bloques equivalen a más trabajo; si los umbrales difieren, contar bloques no es la regla general. Bitcoin Core calcula esta aportación en GetBlockProof.
Los empates de trabajo pueden persistir temporalmente. Los nodos pueden seguir construyendo sobre la rama que prefieren hasta que otro bloque deshaga el empate. El protocolo no necesita que todos tengan la misma punta en cada instante, sino una manera de resolver el desacuerdo conforme llegan información y trabajo adicionales.
La palabra válido es esencial. Una rama que crea dinero prohibido o gasta sin autorización no se vuelve aceptable por acumular trabajo. Los validadores completos aplican las reglas monetarias y de transacciones de forma independiente. La potencia de cómputo puede influir en el orden y la censura, pero no hace que un validador honrado acepte una firma incorrecta bajo las mismas reglas.
Aun así, un atacante puede intentar sustituir pagos recientes construyendo otra rama válida. Por eso el destinatario interpreta las confirmaciones como confianza acumulada, no como una garantía absoluta de permanencia. El argumento habitual de seguridad supone, entre otras cosas, que la minería honrada dispone de suficiente capacidad de trabajo y que la red propaga los bloques adecuadamente. Una partición o un nodo muy aislado cambian la situación.
Bitcoin ajusta el umbral exigido para mantener el intervalo medio entre bloques cerca de su objetivo cuando cambia la potencia de cómputo. La red principal suele reajustarlo cada 2.016 bloques, con límites sobre el cambio. Las reglas están implementadas en el código de prueba de trabajo de Bitcoin Core. Un minero no puede elegir libremente una dificultad menor para obtener bloques más fáciles.
3.4 Remunerar la operación y definir la emisión
El registro necesita una regla para crear dinero, además de transferirlo. Bitcoin sitúa una transacción coinbase especial al principio de cada bloque. La suma de sus salidas puede reclamar, como máximo, el subsidio del bloque más las comisiones de las transacciones incluidas. Reclamar menos está permitido; reclamar más invalida el bloque.
Al diseñar DCoin debemos especificar el calendario de subsidios: «minar crea monedas» no es una política completa. Una distribución inicial, una emisión fija por bloque o una secuencia decreciente producen incentivos y trayectorias de oferta diferentes. Las comisiones también necesitan un destino definido. En nuestro ejemplo, quien produce el bloque puede reclamarlas mediante la coinbase; no se envían a una cuenta central del sistema.
El subsidio inicial de Bitcoin era de 50 BTC. Se divide por dos cada 210.000 bloques y, al truncarse a satoshis enteros, termina llegando a cero. El calendario da una emisión máxima por subsidios ligeramente inferior a 21 millones de BTC. No promete que exactamente 21 millones sigan disponibles: pueden reclamarse recompensas incompletas y perderse claves. La emisión se define por altura, no por una fecha del calendario ni por el número de mineros. La implementa GetBlockSubsidy en Bitcoin Core.
Las recompensas introducen un incentivo económico, pero los incentivos son supuestos que analizar, no pruebas de que nadie atacará. Minar tiene costes operativos y de capital. Un participante puede perseguir objetivos externos al protocolo, y el valor de interrumpir un sistema de pagos no tiene por qué coincidir con la siguiente recompensa. Al reducirse la emisión, las comisiones ganan peso en el presupuesto de recompensas; que los usuarios paguen suficientes es una cuestión económica, no una propiedad de la función hash.
3.5 Otras formas de hacer costosa la influencia
La prueba de trabajo es una respuesta al problema de las identidades baratas. Las alternativas cambian el recurso escaso, los supuestos de confianza o ambos. Deben evaluarse como protocolos completos: importan la elegibilidad, la selección de propuestas, la validación, la elección de rama y la finalidad.
| Mecanismo | ¿Qué da influencia a un participante? | ¿Qué hay que examinar? |
|---|---|---|
| Prueba de trabajo | Producir hashes por debajo del umbral exigido | Distribución de potencia de cómputo, propagación, incentivos y riesgo de reorganización |
| Prueba de participación | Capital comprometido según las reglas de validación | Selección, penalizaciones, retiradas, finalidad y supuestos de recuperación |
| Prueba de quema | Evidencia de destrucción irreversible de activos bajo reglas concretas | Qué activo se quema, cómo decae su influencia y cómo se verifica la quema |
| Prueba de tiempo transcurrido | Un intervalo de espera acreditado | Quién garantiza el temporizador e impide multiplicar identidades o temporizadores en paralelo |
| Prueba de importancia | Una puntuación de tenencias o actividad definida por el protocolo | Cómo se calcula y con qué coste puede fabricarse actividad aparente |
La prueba de participación no significa universalmente que «las monedas antiguas pueden minar». Ethereum, por ejemplo, utiliza recompensas, penalizaciones y condiciones de slashing ligadas al comportamiento de los validadores; su documentación explica esos mecanismos. Otros protocolos de participación toman decisiones diferentes.
Quemar monedas puede crear un coste verificable, pero no garantiza matemáticamente que las restantes suban de precio. El precio también depende de la demanda y del comportamiento del mercado. Del mismo modo, una puntuación de actividad solo sirve si fabricar esa actividad no permite fabricar poder de consenso a bajo coste.
Los esquemas de tiempo transcurrido requieren especial cuidado. Si solo un programa local impone la espera, un atacante puede modificarlo o ejecutar muchas copias. El diseño PoET-SGX de Sawtooth usa un entorno de ejecución de confianza; su simulador tiene propiedades de seguridad distintas. La FAQ de consenso de Sawtooth explica expresamente esa diferencia.
En DCoin mantendremos la prueba de trabajo porque permite conectar una regla de selección comprensible con los bytes de Bitcoin de las dos próximas partes. Ya sabemos para qué sirven el umbral y el nonce, por qué importa el predecesor y por qué sigue siendo necesario validar las transacciones después de encontrar un hash aceptable. Es hora de abrir un bloque.