(OroyFinanzas.com) – El largo debate en la comunidad Bitcoin sobre el aumento del tamaño de los bloques y la introducción de numerosos BIPs en los útlimos tiempos han puesto de relevancia cómo no todos los cambios, o equipos de desarrollo, aplican políticas similares cuando se trata de la implementación de las reglas de consenso. Tradicionalmente el equipo de desarrolladores del Bitcoin Core requiere de un consenso generalizado para aplicar cambios tales como el aumento del tamaño de los bloques, mientras que otros cambios no están sujetos a las mismas normas de consenso para implementarse, algo que ha elevado críticas por tratarse de un método inconsistente. Pero esta diferencia puede explicarse, dado que ciertos cambios impactan a diferentes capas de la red Bitcoin, por lo que algunos cambios en las reglas pueden dividir (o bifurcar) Bitcoin en dos, mientras que otros no pueden hacerlo.
Hace ya un tiempo, vimos en OroyFinanzas.com cómo se desarrolla Bitcoin y en qué consisten los BIPs, es decir, las Propuestas de Mejora de Bitcoin. Precisamente, es un BIP (123) presentado en agosto 2015 por el desarrollador Eric Lombrozo el que pretende que cada una de estas propuestas señalen específicamente las implicaciones que tienen sobre las diferentes capas de la red Bitcoin. (Entendemos que resulta relevante destacar que el BIP 123 se presentó tan sólo 11 días después del lanzamiento de Bitcoin XT, el hard fork que proponía un aumento del tamaño de los bloques a 8 MB y que, por primera vez en la historia de Bitcoin, ponía en entredicho el consenso en Bitcoin). Y serán cada una de estas capas, las que determinen la necesidad del nivel de consenso necesario para aplicarlos. En este sentido Lombrozo determina cinco capas en la red Bitcoin:
- Reglas de Consenso
- Capa peer-to-peer
- Servicios de los peers
- Interfaces de Programación de Aplicaciones (APIs) y Llamadas de Procedimientos remotos (RPC)
- Aplicaciones
En el siguiente análisis del periodista Aaron van Wirdum, explicamos las funciones que cada una de estas capas tiene en la red Bitcoin para entender concretamente lo que implican los cambios que se lleven en ellas. Sin embargo, y teniendo en cuenta que los cambios efectuados sobre las capas 2 (Capa peer-to-peer ) y 3 (Servicios de los peers) podrían tener los mismos efectos, los incluiremos en el mismo apartado.
1. Reglas de Consenso de Bitcoin
Las reglas de consenso son las reglas más importantes de Bitcoin. Establecen, entre muchas otras cosas, la cantidad de bitcoins incluidos en la recompensa minera (coinbase), la dificultad de minado, el tipo de prueba de trabajo (proof-of-work) requerido, y, también, el límite del tamaño de los bloques.
Estas reglas son tan importantes porque determinan qué bloques son considerados válidos por todos los nodos completos. Y si todos los nodos completos aplican las mismas reglas de consenso, se asegura que todos ellos mantienen una copia idéntica de la cadena de bloques (blockchain).
En cambio, si los diferentes nodos aplican diferentes reglas de consenso, se corren el riesgo de que unos acepten unos bloques y otros los rechacen, lo que implicaría que los nodos de la red mantienen versiones completamente incompatibles de la cadena de bloques (blockchain), lo que supondría que la red Bitcoin quedaría dividida.
Las reglas del consenso de Bitcoin se pueden modificar de dos maneras:
1) A través de un cambio que añade reglas adicionales al protocolo (haciendo que los bloques actuales sean inválidos). Es lo que se conoce como soft fork o bifurcación blanda. Estos tipos de cambio requieren de la mayoría de la potencia de hash de la red para que sean efectivos. Y en este caso, los bloques que se producen bajo las nuevas normas serán válidos también bajo las viejas reglas, por lo que los nodos que no actualizan continuarán considerando la cadena más larga como válida.
En cualquier caso, los mineros no actualizados podrán producir bloques que no son válidos bajo las nuevas reglas, lo que implicará un desperdicio de la potencia de hash. Y los nodos completos no actualizados ya no serán capaces de verificar los nuevos bloques bajo las nuevas reglas, por lo que tendrán que esperar confirmaciones adicionales para alcanzar el mismo nivel de seguridad.
Por estas y otras razones, el equipo de desarrollo del Bitcoin Core ha asegurado que se requerirá normalmente una súper mayoría del 95 por ciento de la potencia de hash para ponerse de acuerdo en los soft forks.
2) A través de un cambio que elimina las reglas del protocolo (haciendo que los bloques que antes no eran válidos, sí lo sean ahora). Es lo que se conoce como hard fork o bifurcación dura. Un hard fork requiere que todos los nodos completos de la red adopten dichos cambios, es decir que actualicen el software. Cualquier nodo que no implemente el cambio podría no seguir la cadena más larga, ya que podría considerar que dicha cadena es inválida y permanecerá en la cadena “vieja” que es la que reconoce como válida. Esto podría dividir la red Bitcoin. El tiempo que esa división de la cadena de bloques dure no es en realidad una cuestión técnica, sino más bien un debate sobre política, sociología, economía, teoría de juegos y mucho más.
Los cambios a través de soft forks a las reglas de consenso sin un consenso, podrían en el peor de los casos, provocar que una minoría de los mineros desperdicien potendia de hash y ligeramente degradar la seguridad de los nodos completos.
Los cambios a través de hard forks de las reglas de consenso sin consenso podrían en el peor de los casos dividir la red Bitcoin en dos.
2. Capa peer-to-peer (p2p o entre pares) de Bitcoin
La capa peer-to-peer (p2p o entre pares) de la red Bitcoin engloba la forma en cómo se comparten datos y qué datos son los que son compartidos entre los nodos que forman la red. Esto incluye las normas de protocolo para enviar y recibir transacciones y bloques, así como paquetes de datos especiales como Testigos Segregados (Segregated Witness) o Invertible Bloom Lookup Tables (IBLT).
Lo más importante, es que la capa peer-to-peer debe garantizar que los nuevos bloques creados encuentren su camino a través de toda la red para que, de esta manera, la potencia de hash al completo pueda focalizarse en resolver el siguiente bloque, así como que todos los nodos reciban correcatamente los paquetes de datos necesarios para verificar la validez de los bloques. Si la transmisión de ambas cosas, es decir, si la política de transmisión, no es tremendamente efectiva o falla, el resultado sería que los diferentes nodos trabajarían sobre diferentes versiones de la cadena de bloques (es lo que se conoce como una bifurcación de la cadena de bloques), al menos hasta que la cadena más larga sea recibida y verificada por toda la red de nuevo, y todos los nodos sigan trabajando sobre la misma versión.
Pero, a diferencia de las reglas de consenso, necesariamente no supone un gran problema si cada nodo único aplica la política exacta de transmisión o no, dado que si la mayoría de los nodos transmiten los bloques a al menos ocho pares, por lo que este amplificador debe garantizar que todos los nodos reciben todos los bloques, aunque algunos de ellos no reenvíen correctamente.
Los nodos tienen aún más margen de maniobra cuando se trata de la transmisión de las transacciones. La mayoría de los nodos de la red Bitcoin hoy en día utilizan una política de “primero vista” (first seen), es decir, si reciben dos o más transacciones en conflicto, rechazan ésta última. Sin embargo, un creciente número de nodos está aplicando variaciones de las políticas “reemplazar por tasa o comisión”(replace-by-fee), lo que significa que recogen las transacciones que incluyen las tasas más altas – independientemente de lo que ocurriera primero. Además, algunos nodos rechazan ciertos tipos de transacciones por completo, o no retransmiten cualquier transacción en absoluto.
Dicho esto, los mineros deciden en última instancia las transacciones que se incluyen en los bloques, y por qué. Es únicamente cuando las política de reenvío de transacciones son muy variables, o son lo suficientemente restrictivas, que, por estas mismas razones, podría llegar a ser impredecible qué transacciones son confirmadas.
Por tanto, los cambios efectuados en la capa peer-to-peer sin consenso podrían en el peor de los casos, dividir la red. Este riesgo existe si los bloques no pueden encontrar su camino a lo largo de toda la red. La división, sin embargo, se resolverá automáticamente una vez que la red al completo vuelve a conectarse. Como ya vimos en una artículo anterior, estas divisiones o bifurcaciones momentáneas de la cadena de bloques suelen producirse frecuentemente sin que impliquen un mayor riesgo para la red, sino únicamente la pérdida del poder de cómputo de los nodos que continúan trabajando en la cadena de bloques equivocada.
Si los cambios incluidos sin consenso en la capa peer-to-peer afectan únicamente a la transmisión de las transacciones, el peor escenario podría resultar en que ciertas transacciones no se confirmen. También podría implicar una aumento de la desconfianza en las transacciones con cero confirmaciones. Pero en ningún caso la red podría quedar dividida como consecuencia de estos cambios.
3. Interfaces de Programación de Aplicaciones (APIs) y Llamadas de Procedimientos Remotos (RPC) de Bitcoin
La capa de la Interfaces de Programación de Aplicaciones (APIs) y las Llamada de Procedimiento Remotos (RPC) es una capa de comunicación en la parte superior del protocolo peer-to-peer. Muchas aplicaciones de software Bitcoin – tales como carteras móviles y exploradores de la cadena de bloques – se comunican con la cadena de bloques través de estas capas mediante la conexión a una API o biblioteca de software.
Si una de estas capas falla, todas las aplicaciones de software conectadas serán incapaces de comunicarse de forma fiable con la red Bitcoin. Las carteras móviles no sabrán si han recibido bitcoins, y los exploradores de la cadena de bloques no podrán saber si ha sido resuelto un nuevo bloque. Sin embargo, todos los demás usuarios de Bitcoin no se verán afectados por estos fallos y la red Bitcoin seguirá funcionando correctamente.
Los cambios en la capa de APIs y RPC sin consenso podrían, en el peor de los escenarios, desconectar por completo a los usuarios de estas capas de la red Bitcoin. Pero tales cambios no afectan a la red Bitcoin en sí, ni pueden dividir la misma.
4. Aplicaciones de Bitcoin
Por último, la red Bitcoin consta de la capa de aplicaciones que se refiere a cómo las aplicaciones de software Bitcoin crean y utilizan ciertos tipos de datos. Esta capa es útil para sincronizar todas la aplicaciones, pero en realidad no tocan la red Bitcoin directamente.
Esta capa incluye, por ejemplo, los formatos de las direcciones, la generación de claves privadas o las copias de seguridad de las carteras. Si una cartera genera una dirección que otra cartera no considera válida, realizar transacciones entre ellas será imposible. O si una cartera utiliza un método para crear una dirección semilla de una copia de seguridad, y otra cartera utiliza otra, los usuarios no pueden recuperar sus claves privadas con cada cartera. Lo mismo ocurre con las copias de seguridad de cartera.
Los cambios en las capas de aplicación sin consenso podrían, en el peor de los escenarios, impedir que algunos usuarios realicen transacciones entre sí, y provocar otros inconvenientes. Pero tales cambios no afectan a la red Bitcoin en sí, ni pueden dividir la misma.
