En
otro hilo he expresado mi opinión de que bitcoin tiene un problema de diseño en la generación de bloques mediante la "prueba de trabajo". Este problema se manifiesta con dos síntomas:
- La absurda carrera a ninguna parte de la potencia de cálculo, que ahora experimenta un repunte importante con los ASIC: es como el juego de la cuerda, con dos equipos tirando de ella; de repente uno ata un burro y parece que va a ganar, hasta que el otro equipo ata otro burro; después un caballo, después un tractor, después un camión... y ambos equipos siguen exactamente donde estaban al principio, pero habiendo invertido estérilmente en todos esos recursos. Pues bien: ¿en qué beneficia esa carrera a bitcoin? ¿acaso es más seguro con más potencia de cálculo? ¿Para qué gastar tanta energía y recursos tontamente?
- Favorece la creación de "pools" centralizados, rompiendo el carácter distribuido de la red. Eso no sólo no ayuda al proyecto, sino que lo perjudica gravemente
Ante esta situación hay una solución relativamente sencilla de haberse pensado antes, porque ahora es imposible introducirla en el protocolo de bitcoin. Aquí la dejo, por si alguien la considera para la creación de una nueva criptomoneda.
La prueba de trabajo consiste en "hashear" la cabecera del bloque y ver si el resultado, interpretado como un número, está por debajo de un cierto valor objetivo ("target"), que es tanto más pequeño cuando mayor es la dificultad. Si es así, el nodo emite el bloque y los demás pueden probar fácilmente que es válido "hasheando" la cabecera.
Si no tiene éxito en este proceso, el nodo puede modificar un parámetro de la cabecera del bloque que es como una especie de contador (en el argot anglosajón: "nonce"); lo incrementa y vuelve a "hashear" y comprobar con el objetivo. Lo normal es empezar con el contador a 0 e ir subiendo hasta que el contador se "desborda". Es decir, suponed que el contador admite sólo 4 cifras decimales; pues empezando en 0 tenemos 10.000 oportunidades de probar (hasta el 9999) antes de que se desborde.
Si hemos llegado sin éxito al punto en que el contador se desborda, no tiene sentido empezar desde 0 otra vez, porque ya sabemos que no vamos a conseguir nada. Hay que modificar otro parámetro de la cabecera, puesto que sabemos que las funciones "hash" son muy sensibles a un cambio nimio. Hay otros dos parámetros que se pueden cambiar: el "hash" de las transacciones (hablaré de esto más tarde) y otro contador, que se incrementa en 1 con cada segundo que pasa y que, en principio, es más rápido que el anterior.
Por tanto, despues de nuestros 10.000 intentos, esperamos 1 segundo y volvemos a intentarlo. El problema es que no es necesario esperar... ¡porque no nos da tiempo a desbordar el contador real, que contiene 32 cifras binarias! Y 32 cifras binarias supone la friolera de probar 2^32 = 4x10^9 hashes antes de que el contador de tiempo se incremente. Es decir, tendríamos que tener una potencia de cálculo de 4 GH/s para desbordar el contador "nonce" antes de que se incremente el contador temporal. Esto favorece repartir el trabajo en "mineros", asignando a cada uno una porción del "nonce".
Pues bien,
mi propuesta es rebajar el "nonce" a 16 bits, que es equivalente a 2^16 = 65.536 hashes. Por tanto, con una potencia mínima de 65 kH/s, fácilmente conseguible incluso con CPUs, cada nodo puede desbordar su "nonce" y esperar a que el contador de tiempo se incremente. Salvo que sea muy impaciente (que lo será, si hay BTCs de recompensa de por medio) y decida manipular la otra parte de la cabecera que es manipulable: el "hash" de las transacciones; en particular, la transacción de generación, que es tremendamente voluble y cuya manipulación altera la cabecera del bloque a discreción.
Efectivamente, habría que cambiar también la forma en que se construye la transacción de generación, pero ahora no quiero extenderme más. Simplemente supongamos por ahora que esto también se puede controlar y veamos las implicaciones.
Al no poder forzar la creación de hashes, cada nodo entra en una especie de lotería en que todos tienen el mismo número de boletos y las recompensas se van repartiendo al azar entre todos. El poder de cálculo de la red es simplemente 65 * (número_de_nodos) kH/s. Y, lo que es más importante, no tiene sentido la minería en "pools", puesto que cada nodo puede cumplir por sí mismo la máxima tasa de minado eficiente.
Por supuesto, la dificultad base tiene que ser inferior a la actual. La podemos calcular de forma que un nodo solitario, trabajando a 65 kH/s, tarde un promedio de 10 minutos en generar un bloque. Esto es: 2^16 * 600 ~ 2^25 (en lugar de 2^32 como es ahora). La dificultad de generar un nodo se calcularía como ahora, de forma que toda la red genere en promedio un bloque cada 10 minutos; y ese número sería muy parecido al número de nodos conectados. Si hay 1000 nodos la dificultad es ~1000, si hay 1 millón, ~1 millón.
Aún así, los usuarios pueden hacer "trampas". Supongamos que un tipo quiere multiplicar sus ganancias y se dedica a instalar nodos, contratando servidores dedicados y/o usando todos los ordenadores a los que tiene acceso como nodos. ¡Esta persona multiplicaría sus posibilidades de recompensa! Sí, pero
a costa de incrementar la robustez de la red, haciéndola más resiliente con más nodos. Es decir, la codicia de los usuarios rema a favor de los intereses de la red.
Y, por último, la red sería también más robusta que la actual, puesto que para controlar el 51% de la potencia de cálculo habría que controlar el 51% de nodos.
¿Qué os parece?