Consenso

14 febrero 201718 enero 2019

Este nuevo anexo sobre el consenso, con el que pretendemos ampliar y consolidar los conocimientos adquiridos por los lectores del libro, también se lo tenemos que agradecer al brillante trabajo de Jaime Núñez Miller, socio fundador de Bankabit y de Zentank, veterano de la comunidad Bitcoin y responsable del capítulo “Criptografía y consenso aplicado a la blockchain”. Como bien sabemos, el término consenso es inherente a la tecnología blockchain pero ¿cómo lo logramos? ¿cómo funcionan los sofisticados mecanismos que lo hacen posible? ¿pueden surgir nuevas propuestas mejoradas en este ámbito concreto? Como nos explica Jaime, las constantes propuestas innovadoras del universo blockchain tampoco escapan a las reglas del consenso.

***

La innovación en el terreno de las blockchains no ha sido exclusivamente de tipo técnica. También se han propuesto mejoras para reemplazar las pruebas de trabajo basadas en SHA256, pero también se han diseñado y puesto en marcha blockchains alternativas que exploran distintos aspectos sociales y económicos. Algunas como Ethereum se orientan a la ejecución de contratos complejos, otras a los mercados de valores o de predicciones y otras como Monero o Dash a la privacidad. En todas ellas se necesita definir la forma en la que se establece un consenso sobre el estado de la blockchain.

Para poder llegar a un consenso en un sistema descentralizado de tipo blockchain se necesita conocer con anterioridad cuáles serán las reglas de consenso, es decir, las que deberán cumplir los bloques para ser admitidos en una cadena. En este punto sería interesante recordar el anexo que hemos escrito sobre el dilema de los generales Bizantinos.

Los nodos que forman la red son los responsables de actualizar la blockchain y son ellos quienes verifican los bloques antes de incorporarlos a la cadena.  Los mineros por su lado son los encargados de crear los bloques y por tanto quienes ostentan el poder último para decidir cuál es la cadena legítima en caso de discrepancia.

En el caso de las blockchains públicas cualquiera puede ser minero y bastará con reunir los requisitos y recursos necesarios. En las blockchains privadas en cambio el consenso depende de las instituciones participantes, que actuarán como partes de un contrato privado que es el que en última instancia regula las relaciones entre ellos.

El consenso en cadenas públicas es en donde encontramos un cambio de paradigma capaz de transformar todo aquello que conocemos hasta el momento. Como en el consenso descentralizado no existe ninguna autoridad a la que recurrir, son las propias reglas del juego las que deben incorporar los incentivos necesarios para lograr que a las partes les compense actuar de forma honesta. Mejor dicho, hay que partir de la presunción de que los participantes en la red no se comportarán de forma “honesta” y tomarán sus decisiones pensando únicamente en maximizar su rentabilidad. Si los incentivos están bien planteados, será su propio interés quien les lleve a actuar de forma honesta. Este principio tiene su base en la teoría de juegos y en el equilibro de Nash, y es la clave para la estabilidad de todo el sistema. Cualquier cambio que se realice en las reglas de consenso y concretamente en aquellos que establecen los incentivos es por tanto sumamente delicado.

En una blockchain privada no se requiere un consenso mayoritario y basta con que intervengan exclusivamente las partes intervinientes con arreglo al estatuto o contrato que hubieran firmado. En una blockchain de consenso descentralizado todos los cambios requieren la aceptación de la mayoría, y en consecuencia se necesita un protocolo que defina en qué consiste esa mayoría. Para ello se utilizan principalmente dos tipos de algoritmos:

 

  1. Pruebas de trabajo (Proof of Work), en donde tienen más voto los que realizan una mayor cantidad de trabajo. Es el sistema que ya hemos visto en hashcash y el principal mecanismo de consenso en las blockchains públicas más conocidas como Bitcoin y Ethereum.
  2. Pruebas de participación (Proof of Stake) , en donde tienen más voto quienes poseen un mayor porcentaje de los tokens emitidos. Se utiliza por Nxtcoin, Peercoin, Bitshares o otras criptomonedas.

 

Pruebas de trabajo (Proof of Work)

Para entender las reglas de consenso basadas en pruebas de trabajo recurrimos a algoritmos como hashcash que surgieron como una medida de tipo económico para evitar el spam. Como ya hemos visto en su correspondiente anexo, Hascash exigía al usuario incurrir en un coste (tiempo de proceso) para poder enviar un correo. El correo debía llevar una prueba de ese trabajo. Pero ¿por qué no utilizar esas mismas pruebas de trabajo también para otros servicios online? Esta es la pregunta que debió hacerse el criptógrafo norteamericano Hal Finney cuando comenzó a desarrollar su sistema de pruebas de trabajo reutilizables (RPOW, Reusable Proof of Work). La idea de Finney radicaba en que los usuarios pudieran generar tokens universales (“fichas” o “claves” en formato digital)  y utilizarlos luego para consumir también otro tipo de servicios, y no sólo el correo electrónico. Una ventaja adicional sería poder acumular esos tokens para usarlos más tarde o vendérselos a otros. Los proveedores seguirían sin ganar “dinero real” con ello pero sí que evitarían los abusos en su servicio.

Esas pruebas de trabajo reutilizables y universales es lo que hoy día llamamos criptomonedas.

La idea era buena, pero viable sólo si esos tokens eran capaces de conservar su valor en el tiempo, o dicho de otra manera, si no se podían falsificar. Finney andaba resolviendo algunos flecos con la seguridad de sus tokens cuando a finales de 2008 alguien con el alias Satoshi Nakamoto propuso un sistema llamado Bitcoin. El protocolo Bitcoin resolvía varios de esos problemas mediante una red descentralizada de tipo P2P (Peer to Peer) en conjunción con hashcash.

Bitcoin en el fondo no es más que un registro inmutable con la historia de todos los tokens desde su creación inicial. Sería algo parecido a esto:

 

Movimientos del token Propietario del token
1.Creación del token por Usuario A
2.Transferencia a Usuario B
3.Transferencia a Usuario C
4.etc.

En vez de usuarios con una identidad física el sistema utilizaría claves digitales, claves asimétricas (pública y privada) creadas por los propios usuarios. En el cuadro de arriba sustituiríamos “Usuario A” por “Clave A”, “Usuario B” por “Clave B”, etc.. Esas claves son las que luego permiten hacer transacciones mediante un sencillo sistema de firma electrónica.  Como el historial de todas las transacciones es público se facilita que cualquiera pueda verificar tanto el origen válido o legítimo de cada token como el cumplimiento de las normas, de la misma forma que en un campeonato de ajedrez todos pueden verificar que los jugadores mueven las fichas correctamente.

En una cadena de bloques basada en pruebas de trabajo se podrían crear situaciones de conflicto en las reglas de consenso por ejemplo cuando alguien con suficiente potencia de minado quisiera atacar la red modificando las reglas de forma hostil, es decir, sin antes alcanzar un consenso, o cuando una actualización del protocolo produzca un cambio imprevisto en esas reglas de consenso.

En cualquiera de estos casos los usuarios de la red se podrían llegar a encontrar con dos registros (blockchains) distintos. ¿Cómo determinamos entonces cuál de ellos es la blockchain “real”, la respaldada por la mayoría? Como ya vimos antes, la solución de Satoshi consistía en crear una cadena de hashes para acumular pruebas de trabajo. La blockchain más votada será aquella que tenga acumulada un mayor número de pruebas de trabajo.

Veamos un ejemplo. En este gráfico vemos las tres funciones básicas de la red Bitcoin.

funciones básicas red bitcoin

Los nodos son los encargados de validar los bloques y las transacciones, y de actualizar la blockchain. Hay que tener en cuenta que en muchos casos se habla de nodos refiriéndose también a los mineros, pero las funciones son distintas.

Los wallets generan las transacciones, las firman y las envían a los nodos para ser validadas y puestas en una lista de espera (mempool) a disposición de los mineros.

Los mineros generan los bloques de la cadena. Para ello obtienen el merkle tree de las transacciones que quieran escoger entre aquellas que se ya se encuentran en la lista de espera. El root hash de ese árbol de merkle lo usan como parte del mensaje a hashear con un algoritmo de prueba de trabajo tipo hashcash. El minero que logra encontrar el hash válido se lo comunica a los demás nodos, que lo verifican y actualizan la blockchain. Sólo entonces los mineros reinician sus procesos y comienzan a generar el siguiente bloque incentivados por los nuevos bitcoins que obtendrán si logran dar con el hash requerido por el nivel de dificultad.

Gráfico de Markle root hash bloque anterior

En caso de encontrarnos con dos cadenas, la “real” será la más larga, la respaldada o votada por la mayoría al igual que en el supuesto de los generales Bizantinos en el dilema resuelto por Satoshi.

Mientras los mineros honestos mantengan la mayor parte de la capacidad de proceso (hashrate), su cadena crecerá más rápido que cualquier otra. Si un atacante llegara a tener más potencia que todos los demás juntos, podría cambiar las reglas de forma unilateral, pero en ese mismo momento o probablemente mucho antes, el sistema se devaluará hasta el punto en el que dicho ataque no sea rentable. Los inversores habrán abandonado el sistema hasta que la situación se solucione.

Los mineros son quienes obtienen las pruebas de trabajo y por tanto los únicos con “derecho” a voto. Es su potencia de cálculo y el gasto que realizan para obtenerla la que les otorga ese derecho. Pero los mineros no están sólos en la red, dependen también de los nodos para validar las transacciones de los usuarios y mantener la blockchain. Los usuarios por su lado son quienes dan valor al servicio y por tanto quienes ponen precio a los tokens. Todos ellos son esenciales y todos tienen sus propias estrategias en el juego. Es comprensible que los cambios en el protocolo provoquen bastante preocupación, pues alguno de esos cambios podría, voluntaria o involuntariamente por ejemplo, desequilibrar el sistema, llevar a una mayor centralización o perjudicar la privacidad de los usuarios.

Supongamos que una actualización en las reglas provoca la bifurcación de la cadena. Durante un tiempo coexistirían dos blockchains esperando a que los mineros se decidieran por una de ellas. Sabemos que esa elección la harán pensando en la mejor estrategia para sus propios intereses económicos y por tanto minarán en la cadena que contenga los tokens más valiosos. Como el valor de los tokens no lo determinan los mineros, sino el mercado, los usuarios y los inversores tienen también la posibilidad de influir en la decisión que tomen los mineros. Basta con que algunos inversores vendan los tokens de una cadena para adquirir los de la otra para ejercer una influencia decisiva.

Por otro lado están también los desarrolladores que tampoco tienen voto y sin embargo todos reconocen que su capacidad para enfocar y abordar ciertos problemas es determinante a la hora de decidirse por una opción u otra . Aunque cualquiera puede hacer un fork del código e iniciar una nueva cadena, es obvio que no llegaría muy lejos sin el respaldo de un reputado grupo de desarrolladores.

En definitiva, un cambio en el protocolo sólo se llega a proponer si tiene de antemano el apoyo de una gran mayoría y especialmente el de los usuarios inversores. Llegados a ese punto, son los desarrolladores quienes publicarán una actualización del software incorporando las nuevas reglas. Esas reglas que no se aplican de forma inmediata. En el propio código se agrega un sistema de activación automática para cuando se alcance un determinado porcentaje de aceptación.  La aceptación se mide por la cantidad de mineros que han adoptado el nuevo software y ese porcentaje se fija por los desarrolladores en función del tipo de modificación que se haya realizado. Cuanto más conflictivo sea el cambio, mayor deberá ser ese porcentaje.

El nivel de difusión se puede observar en la red a medida que los nodos se actualizan, por lo que una vez que se alcance el porcentaje requerido y ese porcentaje se mantenga durante un tiempo predeterminado, las nuevas reglas se activarán de forma automática .

Las propuestas de mejoras en el protocolo Bitcoin se suelen presentar a la comunidad en documentos llamados Bitcoin Improvement Proposals (BIP) y están numerados secuencialmente. La comunidad discute entonces la viabilidad y la conveniencia de cada propuesta y si conviene implementarla. Los debates son públicos y se llevan a cabo en foros online y en conferencias.

Por la forma en la que impactan la red se distinguen dos tipos de cambios en las reglas: los que se hacen con un softfork y los que implican un hardfork.  Un fork (bifurcación o escisión) es un término hace referencia a un proyecto de software que se divide en dos cuando surgen diferencias incompatibles e irreconciliables. En la práctica consiste en que habrá dos copias similares del software que comienzan a desarrollarse de forma independiente a partir de la bifurcación. Los términos softfork hardfork en el ámbito de Bitcoin se refiere en ambos casos a cambios en el código que producen algún tipo de incompatibilidad y por tanto una nueva cadena.

Softfork

Es una escisión temporal de la cadena que se produce por la activación de reglas más restrictivas. El nuevo software valida parte de los bloques creados con el software antiguo e ignora el resto. Los nodos antiguos seguirán validando todos los bloques. Los mineros que trabajan con nodos sin actualizar estarán construyendo una cadena más débil. En este caso lo que importa es que los mineros actualizados sean mayoría.

gráfico bloques y reglas antiguas de validación

Este tipo de fork no es problemático. Como hemos visto, los cambios se activan cuando ya está aceptado por una mayoría de mineros y los incentivos juegan a favor de una rápida adopción por parte del resto. Pero si se diera el caso de una activación prematura sin contar con la mayoría, el fork se comportaría como un hardfork y se crearían dos cadenas en conflicto.

Hardfork

Se trata de una bifurcación definitiva de la cadena que se produce por cualquier relajación en las reglas que haga válidos algunos bloques que en la versión anterior serían rechazados.

Gráfico bloques y nuevas reglas de validación

Los nodos actualizados validarán todos bloques, pero quienes no hayan aceptado los cambios no podrán validar los nuevos bloques. Por tanto, a diferencia del softfork, se requiere que todos los nodos, y no sólo los mineros,  se actualicen. Este tipo de fork debe evitarse siempre que se pueda, pues crearía dos cadenas válidas excluyentes entre sí. Para realizar con éxito un hardfork hace falta que todos los usuarios, nodos y mineros se hayan actualizado antes.

Proof of Work en Ethereum y otras blockchains

Bitcoin implementa un algoritmo de tipo hashcash que consiste en encontrar un hash SHA256 de una determinada dificultad.  Como cabía esperar, la fuerte competencia ha impulsado el desarrollo de procesadores específicos de tipo ASIC (acrónimo de Circuito Integrado para Aplicaciones Específicas o Application-Specific Integrated Circuit en inglés), que sirven para optimizar esta función y realizar cálculos más rápidamente. En la actualidad uno sólo de estos procesadores es capaz de obtener más de mil millones de hashes por segundo.

El riesgo con las pruebas de trabajo es que un pequeño grupo de fabricantes de hardware y de mineros pudieran llegar a tener una parte significativa del poder de computación de la red y llegar a controlarla. Si algún día se diera ese caso, la comunidad cambiaría el algoritmo de consenso mediante un hardfork con el objetivo de inhabilitar a los mineros hostiles.

Ethereum es una plataforma que ha implementado un sistema de consenso distinto con la idea de evitar ese riesgo. Su algoritmo también se basa en pruebas de trabajo como en Bitcoin, pero está modificado para evitar el uso de procesadores ASIC, procesadores que resultan caros de fabricar y que por tanto favorecen la centralización.  El algoritmo usado ahora por Ethereum (Ethash) hace uso de una propiedad llamada en inglés “memory hardness” que provoca que el rendimiento del procesador dependa de la rapidez con la que puede mover datos en la memoria en lugar de por la rapidez con la que realiza operaciones de cálculo. Un experto diseñador de procesadores no podría mejorar mucho lo que ya se logra con las actuales tarjetas gráficas (GPUs) que están al alcance de cualquiera. Si alguien lograra encontrar la forma de mejorar el rendimiento de las memorias, le resultaría más rentable vender la idea a los fabricantes de tarjetas gráficas que fabricar sólo procesadores de minado. Por otro lado ya existe en la industria informática un gran interés en mejorar la velocidad de las memorias y por tanto ya se están dedicando grandes recursos y equipos a ello.

El sistema de prueba de trabajo usado por Ethereum evita parte de la centralización pero sigue sin resolver el problema del todo.  Ethereum tiene previsto cambiar a un nuevo algoritmo de tipo “Proof of Stake” (PoS) cuando se hayan resuelto algunas de las dificultades detectadas y que veremos más adelante.

Casi todos los nuevos algoritmos de pruebas de trabajo, al igual que el usado por Ethereum, intentan evitar el uso de procesadores ASIC y así reducir el coste de minado y la centralización. Algunos ejemplos de esos nuevos algoritmos los podemos ver en casos como Litecoin o Dogecoin que utilizan scrypt, el de Monero que usa cryptonight o Dash que se basa en el X11. Los primeros utilizan una estrategia propia para dificultar el uso de ASICs al igual que hace Ethash y otros como X11 encadenan hasta 11 algoritmos distintos.

Proof of Stake

Las pruebas de participación (PoS o Proof of Stake en inglés) son la principal alternativa a las pruebas de trabajo. Con las pruebas de trabajo los mineros pueden crear una cantidad de bloques proporcional a su potencia de proceso. Con las pruebas de participación, sin embargo, los bloques se crean en una proporción relativa a la cantidad de tokens que tenga cada participante. Existen dos formas de asignar un nuevo bloque a alguno de los participantes en la red:

 

  1. Selección aleatoria. El minado de cada bloque se asigna aleatoriamente por la red a cualquiera de los tokens existentes. Si el propietario de ese token está online, recogerá las transacciones y las comisiones, creará el bloque y lo enviará al resto de la red. Si no está online, la red seleccionará otro token. Con este sistema quien tenga más tokens estará más incentivado a tener su sistema online y así recibir las comisiones que de otra forma perdería. Este sistema es el que usa Nxt (Nxtcoin).
  2. Selección por antigüedad de la moneda. Con este sistema se asigna el bloque a quien haya realizado una transacción con las monedas que acumulen más tiempo desde la última vez que se transfirieron. Se utiliza por Peercoin que lo combina también con un sistema de selección aleatoria.

 

En este tipo de blockchains basadas en PoS no se suelen generar nuevos tokens por lo que la recompensa de los bloques consiste exclusivamente en las comisiones.

Las pruebas de participación ofrecen una ventaja fundamental sobre las pruebas de trabajo y es su menor coste de minado. Con PoS se usan procesadores de consumo ampliamente disponibles en el mercado que tienen un precio mucho más bajo que los ASIC utilizados en la minería Bitcoin. Esto hace que el coste de mantener la red sea menor y por tanto las comisiones a pagar por las transacciones puedan ser también menores.

Otra de las ventajas aludidas es que se reduce el riesgo de un ataque del 51% al requerir que el atacante tenga que hacerse antes con un 51% de los tokens. Sin embargo, aunque se aumenta la seguridad por un lado, también se reduce por el otro. Cualquiera que fuese capaz de negociar la posesión, aunque sólo fuera temporal, de un 51% de tokens, no necesitaría mucho más `para llevar a cabo su ataque. Por el contrario, en la red Bitcoin la adquisición de recursos para iniciar un ataque del 51% tendría un coste real enorme en tiempo y dinero.

En cualquier caso el problema más importante de los sistemas PoS puros es que no sirven para alcanzar el consenso en caso de una bifurcación de la cadena. Los mineros podrían seguir minando en ambas cadenas porque eso no les supone un gasto extraordinario, no tienen ningún incentivo para decidirse por una de ellas. En cambio minar en las dos cadenas de una bifurcación con un sistema de pruebas de trabajo sería muy perjudicial para el minero. Para mitigar este tipo de problemas la mayoría de los nuevos algoritmos de consenso PoS no son puros y resultan de una combinación de PoS y PoW.

Una de las más recientes variantes de las pruebas de participación son las pruebas de participación delegadas (DPoS o Delegated Proof of Stake en inglés). El sistema fué desarrollado para la blockchain de BitShares y algunas variantes del mismo ya se usan por otras criptomonedas. Este sistema es más eficiente que el PoS puro y permite a los pequeños wallets obtener cierto beneficio indirecto aún sin tener su equipo siempre conectado. Con DPoW los wallets pueden delegar sus derechos de participación votando a un determinado minero. Este último se quedará parte de las comisiones y el resto las destruirá aumentando por tanto el valor de todos los demás tokens que siguen en circulación. El porcentaje que se queda el minero delegado lo establecen ellos mismos y es un mecanismo para favorecer la competencia y obtener más votos. Un delegado que se quede con el 80% de las comisiones y destruya el otro 20% probablemente obtendrá más votos que uno que se quede con el 90% y sólo destruya el 20%. También puede obtener más votos si en su “programa electoral” promete dedicar los beneficios obtenidos a una tarea necesaria para la red como desarrollo, marketing, etc., o si representa a una u otra comunidad. En caso de no satisfacer a sus votantes éstos podrán retirarle el voto. Se crea de esta forma un interesante sistema de incentivación política que puede tener otras muchas aplicaciones en el futuro.

El problema de los generales Bizantinos y su importancia en la Blockchain

El conocido dilema de los generales Bizantinos surge en los años 70 del pasado siglo y hasta la aparición de bitcoin en 2009 permanecía irresoluble. En este anexo, Jaime Núñez Miller nos explica cómo la innovación más importante que nos ofrece la tecnología blockchain consiste precisamente en crear ese mecanismo que nos permite alcanzar un consenso entre partes que no se conocen, usando una red pública y potencialmente comprometida. Los generales bizantinos ahora sí tienen una oportunidad.

***

La forma en la que Bitcoin ha demostrado que se puede alcanzar un consenso descentralizado, sin ningún tipo de autoridad central, nos ha abierto todo un horizonte de posibilidades en los terrenos más diversos. La criptografía, las matemáticas, la teoría de juegos e Internet son los cimientos de esta ciencia que ya ha dejado las pizarras para empezar a cambiar el mundo real. Hace tiempo que las ciencias de la computación empezaron a estudiar fórmulas para lograr que un sistema descentralizado pudiera sincronizarse evitando los fallos y posibles ataques en redes abiertas. Para entender exactamente el problema recurriremos a un dilema llamado el “problema de los generales Bizantinos”.

Pero antes, una consideración previa, en el Universo Blockchain cada token de una cadena puede considerarse como un bien digital que, por tanto, puede clonarse, como sucede en la actualidad con todo lo digital. Así que si no se resuelve ese problema conocido como de “doble gasto”, cualquier usuario podría llegar a enviar el mismo token a distintas personas. Resolver este problema es fundamental.

Pero las blockchains disponen de un sistema para evitar ese doble gasto: cada transacción se registra en orden de aparición. Si Manuel le manda un token a Alicia, no podrá más tarde enviarle el mismo token a Bob.

Como las blockchains son sistemas descentralizados, hace falta un método para llegar a un acuerdo respecto al orden en el que se registran las transacciones. Este método, en el caso de Bitcoin se llama “Prueba de Trabajo” (Proof of Work o PoW en inglés)

Para entender cómo funciona la “Prueba de Trabajo” es fundamental saber qué es y cómo funciona un hash. Confiamos que los lectores del libro ya tengan el suficiente conocimiento al respecto.

Este problema que acabamos de describir deriva de uno de los dilemas clásicos en seguridad para sistemas descentralizados conocido como el problema de los generales Bizantinos. Se le llama así porque en su formulación típica plantea el caso de un grupo de generales del ejército Bizantino que están dispersos y que deben ponerse de acuerdo en atacar una ciudad o en retirarse. El plan sólo será un éxito si la mayoría ataca al mismo tiempo o se retiran. Sólo se pueden comunicar entre ellos mediante mensajes. No hay ninguna autoridad que los coordine y puede que alguno de ellos sea un traidor e intente sabotear el consenso.

Hasta que Satoshi Nakamoto no publicó el protocolo Bitcoin en el año 2009, no se conocía ninguna solución práctica a este problema.

La original propuesta de Satoshi hace uso de un sistema inventado en 1997 por el criptógrafo inglés Adam Back, llamado hashcash y que pretendía poner freno a los envíos de spam masivo. Un texto más elaborado al respecto está en este otro anexo. A forma de breve resumen, la idea era imponer un coste no monetario al envío de cada correo. A Back se le ocurrió que los correos podrían incorporar la prueba de que la computadora que lo enviaba había dedicado antes cierto tiempo y recursos para poder enviar ese correo. El coste en electricidad (tiempo de CPU) para enviar un correo podía ser de un céntimo. Quien enviase unos pocos correos al día no notaría nada, pero quien quisiera enviar millones de correos debería dedicar bastante más recursos a ello, imponiéndose de esta forma un coste.

La forma de obligar al ordenador a consumir esos recursos consistía en plantear para cada correo que se quisiera enviar un problema complejo de resolver o “prueba de trabajo”. En el caso de hashcash consistía en hacer el hashing del mensaje una y otra vez (variando cada vez un pequeño dato llamado “Nonce”) hasta encontrar un hash que reuniera unas determinadas condiciones, en hashcash se pedía que empezara por cuatro ceros. Recordemos que es imposible predecir cuál será un hash por lo que la única forma de dar con uno concreto es mediante fuerza bruta.

Si queremos aumentar el coste de enviar un correo, basta con aumentar el tiempo que se tarda en encontrar ese hash (aumentar la dificultad) añadiendo más requisitos al hash, por ejemplo aumentando el número de ceros que debe tener. Para aumentar la dificultad podemos pedir que el objetivo sea que el hash empiece con seis ceros en vez de con cuatro.

El contenido utilizado para calcular el hash debía incorporar una serie de datos además del mensaje de correo en sí, y en especial un contador llamado “Número usado sólo una vez” (Number used Once  o “nonce” en inglés). que cambiaba cada vez que el ordenador calculaba un hash. El nonce es la forma de asegurar que el hash resultante es distinto en cada intento.

Si el hash calculado no comienza con esos ceros, el nonce cambia y se intenta de nuevo, así hasta que aleatoriamente (por fuerza bruta) el ordenador da con un hash que tenga ese número de ceros delante. Recordemos que es imposible saber de antemano cuál será el hash, por lo que habrá que hacer miles o millones de intentos antes de dar con el hash requerido.

Esquema del proceso hashcash para encontrar una prueba de trabajo (hash) con dificultad n

Esquema del proceso hashcash para encontrar una prueba de trabajo (hash) con dificultad n

 

Ejemplo:

Mensaje Contador (Nonce) Contenido Hash del contenido
“Mi mensaje” 1 “Mi mensaje 1” 2e8de37a8849fb5309…
“Mi mensaje” 2 “Mi mensaje 2” 80e81dbf8a0e77c897…
“Mi mensaje” 3 “Mi mensaje 3” a0bbf40f1e545c4930…
“Mi mensaje” 4437 “Mi mensaje 4437” 00008687e1371c27cd…
Nonce En criptografía se llama nonce a un número arbitrario, aleatorio o secuencial que solamente se utiliza una única vez al realizar algún tipo de operación. El único objetivo del nonce en nuestro contexto es introducir un cambio en el contenido a hashear. De esta forma podemos hacer todos los intentos necesarios y cada vez obtendremos un hash distinto.

Dificultad Cuando se pide que el hash comience con una determinada cantidad de ceros, en realidad se requiere que sea “cualquier número inferior a otra cifra ya predeterminada”. A ese número predeterminado le llamamos target (objetivo). Por ejemplo, imaginemos una lotería en la que el bombo tuviera 99.999.999 bolas numeradas desde el cero. Si pusiéramos el target en 00009.999 querría decir que cualquier bola entre la cero y la 9.999 tendría premio y por tanto la primera bola que obtuviéramos con un número inferior a 9.999 sería la bola de la suerte, el número premiado. De esta forma cuanto menor sea el target, mayor será la dificultad y más bolas tendremos que sacar hasta dar con una bola premiada. En nuestro caso sería un hash “premiado”.

Añadir ese hash al mensaje de correo sería como ponerle un sello de correos; pero un sello que fabrica el propio ordenador dedicando recursos a ello. El hash sería aquí la prueba de que se ha realizado un trabajo; algo que demuestra que el remitente ha incurrido en un coste y que por tanto ya puede enviar ese correo. Enviar miles de correos ya no sería gratis. Por desgracia el sistema hashcash no se llegó a generalizar pero sí abrió la puerta a otras muchas ideas.

Volviendo al problema de los generales Bizantinos y ya con las pruebas de trabajo inventadas ¿cómo resolvió Satoshi el dilema? Pues simplemente creando una cadena de pruebas de trabajo. Para entender cómo funciona vamos a visualizarlo de la siguiente forma:

Vamos a suponer que hay cuatro generales y que daremos a cada general un ordenador capaz de recibir y enviar mensajes y calcular hashes. Se ha decidido que cualquier general puede proponer la hora para el ataque, que llamaremos “el Plan» y cualquier plan que se envíe primero deberá ser el Plan oficial a seguir. El problema es que la red no es instantánea, puede haber cortes, etc. y si dos generales anuncian diferentes planes al mismo tiempo, algunos pueden recibir antes el Plan A y otros el Plan B. Nunca sabremos cuál ha sido el primero. Se necesita un sistema para llegar a un acuerdo sobre el Plan a ejecutar.

Para solucionar eso utilizaremos una “cadena de pruebas de trabajo o cadena de votos”. Cuando algún general decida comunicar a los demás su plan por primera vez, pondrá su computadora a buscar un hash de una dificultad predeterminada, tal y como se hacía con hashcash. Esta vez el mensaje a hashear es el plan (por ejemplo, un plan sería “Atacar a las 22:35 h”) y se ha establecido que la dificultad del hash, para que sea aceptado por los demás, es que tenga al menos cuatro ceros delante. Se ha previsto que sumando la potencia de sus ordenadores, alguno de los cuatro generales llegará a encontrar un hash de esa dificultad en un plazo aproximado de 10 minutos. Eso quiere decir que entre todos se podrá crear un voto cada 10 minutos. Se ha acordado que el plan que más votos tenga al cabo de dos horas será el plan a ejecutar. En ese tiempo ya habría unos 12 votos y si el ordenador entregado a cada uno tiene la misma potencia, la probabilidad de encontrar un hash (votar) será igual para todos y por tanto la media sería de tres votos por cabeza en ese plazo de dos horas. La mayoría habrá podido votar y por estará enterada del plan.

Cuando un general logre enviar un plan con su hash correcto, ese será el primer voto válido y el primer eslabón de esa cadena. Enviará el número de voto, el plan, el nonce y el hash a todos los demás. Seguidamente todos ellos empezarán a buscar el segundo hash usando además el hash anterior como parte del contenido a hashear.

Voto:   1

Plan:   Atacar a las 22:35 h

Voto:   2

Plan:   Atacar a las 22:35 h

Hash 1: 000038852091758a4f9…
Nonce:  11633 Nonce:
Hash 1: 000038852091758a4f9… Hash 2:

El general que encuentre el siguiente hash (el segundo voto de la cadena) se lo enviará a los demás para que alguno de ellos logre crear el tercer voto y así sucesivamente. Cada vez que un general encuentra y publica el hash, está emitiendo un voto por el plan que contiene esa cadena.

Grafico votación nodos

En poco tiempo se empezará a formar una cadena de hashes o pruebas de trabajo enlazadas entre sí. Pero ¿para qué se necesita una cadena? En esencia para llevar la contabilidad de los votos y que se puedan verificar independientemente por cada uno de los participantes. Cada vez que reciben un nuevo voto y antes de sumarlo a su copia de la cadena realizarán las siguientes comprobaciones:

  1. ¿Comienza con cuatro ceros el hash del nuevo voto?
  2. ¿Se obtiene ese hash con los contenidos
    hash (número de voto + el plan + hash del voto anterior + noce)?
  3. ¿Es el plan el mismo que el del voto anterior?

Cada general puede verificar esos datos e ir añadiendo los votos recibidos a su copia de la cadena.

Dos cadenas

Hasta ahora sólo hemos visto el caso de una cadena, un único plan al que votar, pero si alguno de los generales hubiera publicado otro plan de forma simultánea al primero, los generales podrían llegar a tener dos cadenas distintas, cada una con un plan diferente. En ese caso necesitan elegir a qué plan votar y lo harán ignorando aleatoriamente una de las dos cadenas.  A medida que se vayan emitiendo votos una de las dos cadenas tendrá ya una ventaja palpable para todos.

Gráfico de 2 cadenas en una blockchain

Como a la mayoría les interesa llegar a un acuerdo ignorarán el plan que tenga menos votos y votarán al que más votos tenga acumulados. Recordemos que les da igual a qué hora atacar, lo importante es que estén de acuerdo en un mismo plan y así garantizar el éxito. Como veremos más adelante en el capítulo que explica el funcionamiento de la blockchain de Bitcoin, ese incentivo es vital para mantener el consenso. En el caso de Bitcoin consiste en lograr los nuevos bitcoins y comisiones que se generan con cada bloque.

En definitiva, la cadena más larga, la que haya acumulado más pruebas de trabajo y más tiempo de proceso en esas dos horas acordadas, es la más votada. Ahora ya podrán atacar sabiendo que la mayoría de generales apoyan el mismo plan. Esa es la innovación más importante que ofrece la tecnología blockchain, dotarnos de un mecanismo que nos permite alcanzar un consenso entre partes que no se conocen, usando una red pública y potencialmente comprometida. Los lectores del libro ya sabrán cómo Satoshi Nakamoto mejoró este mecanismo, aplicándolo a la construcción de una blockchain.

Apasionado por la continua transformación social propiciada por la tecnología y de la nueva economía P2P. Desde 2012 es asesor de desarrollo estratégico, gestión de proyectos y formador de mandos en empresas multinacionales y start ups dentro del ecosistema Blockchain. A lo largo de su carrera ha trabajado en el sector financiero (FinTech) y turismo en facetas vinculadas a tecnología, marketing digital y desarrollo de negocio en distintos países. Autor y productor de la primera novela gráfica del mundo sobre Bitcoin (BitcoinComic.org) y "Blockchain: la revolución industrial de Internet (LibroBlockchain.com), así como de juegos móviles, inspirados en el mundo de las criptomonedas, desde MoneyFunGames.com. Estudió en la Universidad Pontificia Comillas-ICADE E-4 en Madrid/España y ESB Reutlingen/Alemania.