Fundamentos de blockchain: hashes, consenso, finalidad y compromisos

Quita los gráficos de cotizaciones y la jerga, y lo que queda es una pregunta concreta y de verdad difícil a la que responde una blockchain: ¿cómo puede un grupo de partes que no confían entre sí, y que no pueden apoyarse en ninguna autoridad única, ponerse de acuerdo sobre la misma lista ordenada de hechos? La investigación en sistemas distribuidos lleva décadas estudiando ese problema. Lo nuevo en 2008 fue una forma de resolverlo en una red abierta en la que cualquiera puede entrar, salir o mentir, sin saber de antemano quiénes son los participantes.

Esa solución tiene un coste real, y entender tanto el mecanismo como su coste es lo que separa el criterio de ingeniería útil del entusiasmo. Esta guía explica la maquinaria desde las primitivas criptográficas hacia arriba, compara con honestidad las familias de consenso y termina con los casos en los que la respuesta es «usa una base de datos». La parte programable —contratos, gas, tokens— continúa en Ethereum y los smart contracts.

El problema del acuerdo

Imagina un registro compartido sin dueño. Cualquiera puede proponer entradas; algunos participantes están desconectados, otros son maliciosos, y los mensajes llegan desordenados o no llegan. Aun así, dos participantes honestos tienen que acabar con un historial idéntico; de lo contrario, la misma unidad de valor podría gastarse dos veces, una contra cada versión.

Los protocolos clásicos resuelven esto entre un conjunto conocido de participantes, tolerando que una fracción se comporte de forma arbitraria. Su limitación está precisamente en esa palabra, «conocido»: en una red abierta, un atacante puede crear identidades sin límite y ganar cualquier votación. La idea clave de las blockchains públicas es hacer que participar en la decisión sea costoso y medible —quemando electricidad o inmovilizando capital—, de modo que la influencia sea proporcional a un recurso escaso y no al número de nombres que te inventes.

Todo lo demás se deriva de ahí: la estructura de bloques existe para que verificar el historial sea barato, los incentivos existen para que comportarse honestamente sea más rentable que atacar, y las características de rendimiento son el precio de una participación abierta.

Las piezas criptográficas

Tres primitivas hacen todo el trabajo pesado. Ninguna es específica de las blockchains; la combinación sí lo es.

Las funciones hash criptográficas transforman cualquier entrada en un digest de longitud fija, de forma determinista e irreversible, con la propiedad de que cualquier cambio en la entrada produce una salida completamente distinta.

sha256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
sha256("hellp") = fdd7585e08c4e2afd71dcabdb4636c89d557a3f42db9e2040c8bbd1708aa4ce7

Cambia una sola letra y ningún bit de la salida guarda relación con
el anterior. Es el efecto avalancha, y es lo que convierte al hash en
una huella de un documento, un bloque o un historial entero que delata
cualquier manipulación.

Puedes comprobarlo tú mismo con el generador de hashes, que funciona en el navegador: pega un párrafo, cambia una coma y compara los digests.

Las firmas digitales aportan autenticidad sin secretos compartidos. Quien posee una clave privada firma un mensaje; cualquiera que tenga la clave pública correspondiente puede verificar la firma, pero no falsificarla. En una blockchain, una dirección se deriva de una clave pública, así que «poseer» un activo no significa más que tener la clave privada capaz de autorizar su transferencia. No hay restablecimiento de contraseña. La custodia de claves —hardware wallets, esquemas multifirma, firmas de umbral, custodios institucionales— es, por tanto, toda la historia de seguridad para el usuario final, y las pérdidas se deben de forma abrumadora a claves perdidas, no a fallos del protocolo.

Los árboles de Merkle condensan un conjunto de transacciones en un solo digest aplicando hash a pares de hashes, nivel a nivel, hasta llegar a una única raíz.

        root = H( H12 || H34 )
        /                    \
  H12 = H(h1 || h2)     H34 = H(h3 || h4)
     /        \            /        \
   h1=H(tx1) h2=H(tx2)  h3=H(tx3) h4=H(tx4)

h(tx1) = 709b55bd3da0f5a838125bd0ee20c5bfdd7caba173912d4281cae816b79a201b
h(tx2) = 27ca64c092a959c7edc525ed45e845b1de6a7590d173fd2fad9133c8a779a1e3
H12    = bbea820f07f7f89aeea1ab4a354ecea39f2f72accd05c64371522ee371cd0c48

La ventaja práctica es la prueba de Merkle: para demostrar que tx1 está en un bloque de un millón de transacciones, basta con aportar h2, H34 y la raíz, es decir, un número logarítmico de hashes en lugar del bloque entero. Los clientes ligeros, los puentes entre cadenas y las pruebas de fraude de los rollups se apoyan todos en esto.

Bloques, cadenas y estado

Un bloque es una cabecera más una lista de transacciones. La cabecera contiene el hash de la cabecera del bloque anterior, la raíz de Merkle de las transacciones, una marca de tiempo y campos propios del protocolo.

{
  "number": 21493087,
  "parentHash": "0x8f1c...a3d2",
  "transactionsRoot": "0xbbea...0c48",
  "stateRoot": "0x4d7e...91ab",
  "timestamp": 1757232000,
  "proposer": "0x2b9f...77c1"
}

Como cada cabecera lleva el hash de su padre, modificar una transacción antigua cambia la raíz de Merkle de su bloque, por tanto el hash de su cabecera y, con él, la referencia al padre de todos los bloques posteriores. La manipulación no se impide: se vuelve evidente y cara, que es la forma honesta de describir la inmutabilidad.

Existen dos modelos contables. El modelo UTXO trata el valor como un conjunto de salidas no gastadas discretas, cada una consumida por completo y sustituida por salidas nuevas; paraleliza bien la validación y mantiene un grafo de auditoría limpio. El modelo de cuentas guarda un saldo por dirección y lo modifica, algo mucho más natural para contratos programables. Este modelo necesita un nonce explícito por emisor para impedir que una transacción firmada se reenvíe (replay).

Comparativa de las familias de consenso

El consenso decide quién puede añadir el siguiente bloque y cómo se resuelven los desacuerdos.

Con prueba de trabajo, los proponentes buscan una cabecera cuyo hash quede por debajo de un objetivo. La búsqueda es fuerza bruta pura, la dificultad se ajusta para que los bloques lleguen a un ritmo constante, y reescribir el historial exige superar en cómputo al resto de la red. Su seguridad es fácil de razonar, y su consumo energético no es un detalle de implementación, sino el propio mecanismo.

La prueba de participación sustituye el hardware por capital depositado. Los validadores bloquean fondos, son seleccionados para proponer y atestiguar, y pierden parte de su stake —el slashing— ante un mal comportamiento demostrable, como firmar dos bloques contradictorios. Ethereum completó esta transición y redujo su consumo energético en varios órdenes de magnitud sin renunciar a la participación abierta. El compromiso pasa de «la energía es cara» a «el capital se concentra», y buena parte del esfuerzo de diseño se dedica a desincentivar esa concentración.

Los protocolos tolerantes a fallos bizantinos de la familia clásica asumen una membresía conocida y llegan a un acuerdo mediante rondas de votación explícitas, tolerando hasta aproximadamente un tercio de participantes defectuosos. Ofrecen finalidad inmediata y un throughput alto, y encajan de forma natural en redes permisionadas, pero el conjunto de miembros tiene que gobernarse, y eso es un problema político, no técnico.

Pública, privada y permisionada

Una red pública sin permisos deja que cualquiera lea, envíe transacciones y valide. Su modelo de costes es un mercado de comisiones y su supuesto de confianza es «no existe una coalición mayoritaria del recurso escaso».

Una red permisionada admite organizaciones conocidas, a menudo con canales o grupos de privacidad para que cada participante vea solo las transacciones que le afectan. Aquí se sitúan las plataformas de consorcio empresarial: la identidad la emite un servicio de membresía, el consenso es BFT o tolerante a fallos por caída, el throughput es muy superior y la confidencialidad es alcanzable.

Entre ambas, la pregunta honesta es siempre la misma: ¿quién es el adversario? Si los miembros de un consorcio no tienen ningún motivo para estafarse entre sí y un operador neutral es aceptable, una base de datos replicada con un control de acceso sólido y logs de auditoría criptográficos ofrece la mayor parte del beneficio con una fracción de la complejidad. Muchos proyectos de consorcio han llegado discretamente a esa conclusión.

Forks, finalidad y el problema de las reorganizaciones

Cuando aparecen dos bloques válidos a la misma altura, la red se bifurca temporalmente y luego converge siguiendo la cadena que prefiere el protocolo. Los bloques que quedan atrás pasan a ser huérfanos y sus transacciones vuelven al pool. Esto es una reorganización, un suceso normal y esperado, y por eso las aplicaciones esperan confirmaciones antes de dar un pago por hecho. Con prueba de participación y finalidad explícita, esperar al checkpoint finalizado es la garantía más fuerte.

Los cambios deliberados de protocolo también provocan forks. Un soft fork endurece las reglas, de modo que los nodos antiguos siguen aceptando los bloques nuevos; un hard fork las relaja o las cambia, así que todos los nodos deben actualizarse o la red se divide para siempre. Ambos son tanto eventos de gobernanza como de ingeniería.

La regla práctica para cualquiera que integre una blockchain: nunca des por definitivo un evento on-chain en cuanto lo veas. Suscríbete a las señales de confirmación o de finalidad, haz que tus handlers sean idempotentes y prepárate para revertir un efecto a nivel de aplicación si una reorganización elimina la transacción; es la misma disciplina que en cualquier transacción distribuida con compensaciones.

Escalabilidad, coste y layer 2

El trilema de la escalabilidad plantea la restricción: descentralización, seguridad y escalabilidad; puedes tener dos con holgura. Subir el throughput agrandando los bloques encarece ejecutar un nodo, lo que reduce el número de validadores independientes y, con ello, la descentralización.

La respuesta dominante es la layer 2: ejecutar las transacciones fuera de la cadena principal y usar esta solo para la liquidación y la disponibilidad de datos. Los optimistic rollups publican resultados por lotes y abren una ventana de impugnación durante la cual una prueba de fraude puede anularlos. Los zero-knowledge rollups publican una prueba de validez sucinta, de modo que la corrección se verifica matemáticamente y los retiros no necesitan periodo de impugnación. Los canales de pago permiten a dos partes operar en privado fuera de la cadena y liquidar solo el saldo final. Todos heredan la seguridad de la capa base mientras trasladan la ejecución a otro sitio, y todos añaden riesgo de puente, que históricamente es donde se han producido las mayores pérdidas.

Conviene decir los costes sin rodeos: en la capa base, las transacciones se miden y se tarifican según la demanda, el almacenamiento es con diferencia el recurso más caro y la latencia de confirmación va de segundos a minutos. Compáralo con los esquemas de pago inmediato de fundamentos de los sistemas de pago, que mueven valor minorista en menos de diez segundos con un coste marginal casi nulo, y queda claro que una blockchain no compite en throughput ni en precio: solo compite donde la ausencia de un operador de confianza es el requisito.

Cuándo una blockchain es la respuesta equivocada

Ser útil con esta tecnología significa estar dispuesto a decir que no. Un registro compartido es la herramienta equivocada cuando:

• Una sola organización controla los datos. Has reinventado una base de datos con peor latencia y sin DELETE.
• Los participantes ya confían en un intermediario. El intermediario sale más barato.
• Necesitas confidencialidad. Todo lo que hay en una cadena pública es visible para siempre; la privacidad exige mucha maquinaria adicional.
• Debes borrar o corregir registros. El derecho de supresión y los logs de solo anexión están en tensión por naturaleza.
• Los datos se originan fuera de la cadena. Ningún mecanismo de consenso puede verificar que un envío llegó de verdad; ese es el problema del oráculo, y traslada la confianza a quien informa del dato.
• Necesitas miles de transacciones por segundo con baja latencia. Las capas base no están hechas para eso.

La lista complementaria es corta pero real: la liquidación entre entidades que no tienen un operador común natural, las atestaciones de procedencia e integridad en las que los datos subyacentes permanecen fuera de la cadena, y la infraestructura financiera abierta y programable en la que el acceso sin permisos es precisamente lo que se busca. Juzga una propuesta preguntándote si quitar la cadena elimina algo esencial: si la respuesta honesta es que bastaría con un log de auditoría firmado, construye el log de auditoría firmado.

Ideas clave

• Una blockchain resuelve el acuerdo entre participantes desconocidos que desconfían entre sí; por esa garantía concreta pagas en coste, en latencia y en privacidad.
• El encadenamiento de hashes y los árboles de Merkle hacen evidente la manipulación y abaratan las pruebas de inclusión; las firmas digitales convierten la custodia de claves en todo el modelo de seguridad de los usuarios.
• La prueba de trabajo compra seguridad con energía, la prueba de participación con capital en riesgo, y los protocolos BFT con una membresía conocida y finalidad inmediata.
• La finalidad es probabilística en unas cadenas y explícita en otras: espera siempre las confirmaciones y diseña handlers que sobrevivan a una reorganización.
• El trilema saca el throughput de la capa base hacia rollups y canales, que heredan su seguridad pero añaden riesgo de puente.
• Si una sola organización es dueña de los datos, hace falta poder borrar, importa la confidencialidad o ya existe un operador de confianza, elige una base de datos y dilo claramente.