(OroyFinanzas.com) – A falta del buscado consenso en torno al aumento del tamaño de los bloques Bitcoin, el desarrollo de Bitcoin se centra, por el momento, en ampliar la capacidad de la red, aunque lo hace con la sombra del tamaño de los bloques planeando sobre ella. Y es que, si bien existe una hoja de ruta de las implementaciones que se incorporarán en el Bitcoin Core a lo largo de 2016 para añadir una serie de características nuevas a Bitcoin, que cuenta con el visto bueno de la mayoría de la comunidad de desarrolladores, la falta de apoyo al calendario de trabajo de dos de los desarrolladores principales (Gavin Andresen y Jeff Garzik) es latente. A la espera de nuevos avances en encontrar consenso sobre la ampliación del tamaño de los bloques, o de que aparezcan nuevas propuestas que consigan conquistar a la mayoría, lo cierto es que un cambio en el tamaño está relegado de la agenda, al menos durante 2016. Sin embargo, otras opciones que buscan la escalabilidad de la red (Segregated Witness, Lightning Networks, Sidechains…) a través de la introducción de nuevas capas al protocolo son prioritarias.
El desarrollo de Bitcoin avanza, bajo la sombra de la falta de consenso por el tamaño de los bloques
La hoja de ruta fue presentada en la lista de correos del bitcon-dev el pasado 7 de diciembre por el desarrollador del Bitcoin Core y de Blockstream, Gregory Maxwell, y ha recibido el apoyo público de más de 50 desarrolladores. A pesar de que el apoyo es importante, cabe destacar la ausencia de dos de los desarrolladores principales de Bitcoin: Gavin Andresen y Jeff Garzik.
Días más tarde de que Maxwell presentase la que se ha convertido en la hoja de ruta oficial, Andresen y Garzik mostraban públicamente su rechazo al plan de trabajo principalmente por no incluir el aumento del tamaño de los bloques, algo que según entienden repercutirá en un incremento de las tasas en la red, especialmente tras el halving, en el que la recompensa minera se verá reducida a la mitad, pasando de 25 bitcoins a 12,5, y desplazando con ello “Bitcoin a una nueva política económica”, como aseguran.
Hoja de ruta del desarrollo del Bitcoin Core para 2016
Los desarrolladores del Bitcoin Core trabajan con este calendario de trabajo a lo largo de este año para desplegar las siguientes tecnologías en el protocolo:
1. Diciembre 2015: Lanzamiento de la testnet de Testigos Segregados (Segregated Witness) que se lanzó el último día del año, como ya explicamos en otro artículo.
2. Febrero 2016 (Bitcoin Core versión 0.12.0): Verificación Libsecp256k1. La Libsecp256k1 es una biblioteca criptográfica optimizada para la criptografía de curva elíptica que utiliza Bitcoin en las firmas de transacciones que ha sido desarrollada por Pieter Wuille.
En la versión 0.10.0 del Bitcoin Core se cambio de la biblioteca OpenSSL a Libsecp256k1 por considerarla más eficiente y rápida y porque, según explicaban en el comunicado de lanzamiento, “está mejor probada y revisada más a fondo”. Una vez introducida la verificación en la siguiente versión del código, se traducirá en una mayor velocidad en el hardware para verificar a los nuevos nodos completos que se unan por primera vez a la red. Y también se aligerará el tiempo de carga de los nodos Bitcoin existentes. Algo que puede ser muy beneficioso para Bitcoin ya que más nodos, significa una red Bitcoin más robusta y más descentralizada. En concreto la velocidad aumentará “de 500% a 700% en el hardware x86_64 durante la verificación”.
3. Febrero 2016: Funcionalidad de Testigos Segregados completa y lista para revisión general, lo que no implica que no haya que introducir otra serie de cambios. La comunidad entera de desarrolladores podrá participar en la revisión y proponer las mejoras pertinentes.
4. Marzo 2016 (Bitcoin Core versión 0.12.X): Se estima que para esta fecha estará finalizada la implementación de Op_CheckSequenceVerify (CSV), así como, la primera versión de Versionbits, que se introducirá con el BIP 9.
El CheckSequenceVerify (CSV) se implementará con la introducción en el código fuente de Bitcoin de tres BIPs (68, 112 y 113) y consiste en una funcionalidad que permitirá a los usuarios mantener canales de pagos abiertos el tiempo que quieran, con una mejora de 25.000% en la eficiencia bidireccional de dichos canales de pago. Hasta ahora, el CheckLockTimeVerify (CLTV) (BIP 65) que era la funcionalidad que se utiliza en estos canales de pago desde hace muy poco, requiere la confianza en el que recibía la transacción, ya que éste podía alterar el depósito de la transacción por lo que invalidaba el reintegro del mismo, además de limitar los canales de pago en flujo, es decir sucesivos, a canales unidireccionales. La solución que se utiliza actualmente, es la creación de dos canales de pago unidireccionales, en los que ambas partes tienen que incluir un depósito. Sin embargo, el CheckSequenceVerify (CSV) ahorra la necesidad del depósito de ambas partes en caso de que no haya confianza, ya que únicamente será necesario el uso de un canal de pago que será reversible.
Esta implementación permitirá además una mejor implementación de Lightning Network y posibilitará las Sidechains, dos de las opciones más esperadas para la escalabilidad de Bitcoin.
La otra característica que se planea introducir en marzo 2016 es el Versionbits (BIP 9) que permitirá aumentar el número máximo de bifurcaciones suaves (soft forks) que se pueden implementar simultáneamente en el Bitcoin Core.
Actuamente el código limita a uno los soft forks, pero cuando se implemente el BIP 9 podrán ser hasta 29 los soft forks que pueden lanzarse en versiones consecutivas del Bitcoin Core sin tener que esperar a que una mayoría de los nodos haya actualizado su software para que queden activados, como ocurre en la actualidad. Esto hará que las futuras actualizaciones del código se puedan llevar a cabo más eficientemente. Y teniendo en cuenta que la apuesta a corto plazo de los desarrolladores es por la implementación de cambios a través de soft forks, como enfatizaron recientemente en una polémica declaración, parece que esta funcionalidad será bastante utilizada a partir de ahora.
5. Abril 2016 (Bitcoin Core versión 0.12.X): Implementación de Testigos Segregados.
Como ya hemos explicado, la principal característica de Testigos Segregados es que, a través de la reducción del datos de la firma que contienen las transacciones. Con ello se conseguiría una reducción del 75% de la cadena de bloques (blockchain) y permitirá incluir una mayor cantidad de transacciones en cada bloques, que actualmente tienen un tamaño de 1MB, pasarían a ser equivalentes a 4MB sin tener que cambiar su tamaño. Además de otras caracteríticas no directamente relacionadas con la escalabilidad de la red y en las que profundizaremos en otro artículo.
6. También a lo largo del año 2016 se espera que se incorporen otras dos funcionalidades: Bloques débiles (weak blocks) y los Invertible Bloom Lookup Table (IBLTs). La hoja de ruta no detalla, en este caso, la fecha exacta del lanzamiento, y tampoco si dará tiempo a desarrollar las dos funcionalidades antes de que acabe el año o sólo una de ellas. En cualquier caso, ambas van dirigidas a reducir el tiempo de propagación de los bloques creados por los mineros en la red y reducirá la necesidad de ancho de banda. Por lo que una vez implementadas, permitirá que los bloques de mayor tamaño sean más fáciles de manejar por todos los nodos de la red, una de las mayores preocupaciones de los reacios a ampliar el tamaño de los bloques, por las consecuencias que puede tener en la centralización de la red.
Como vemos pues, el desarrollo del Bitcoin Core en 2016 irá dirigido a ampliar la capacidad de la red, a través de diferentes funcionalidades que proponen una serie de soluciones para hacer que la escalabilidad de Bitcoin sea mayor, aunque, de momento, no entra dentro de los planes de la mayoría de los desarrolladores la introducción de un cambio en el tamaño de los bloques, que ha sido uno de los temas reclamados por muchos actores de la industria y de algunos de los desarrolladores principales, y sobre la que existe el consenso generalizado de que es la única solución a largo plazo para que Bitcoin pueda convertirse en una plataforma de pagos de uso generalizado que compita directamente con las que existe actualmente. Sin embargo, también es importante destacar que parte de las actividades de programación del Bitcoin Core durante este año irán dirigidas a mejorar aspectos que harían de un futuro aumento del tamaño de los bloques una implementación más sencilla para todos los nodos.
EPL
Fuente: Bitcoin.org
© OroyFinanzas.com
