Con nuevos lanzamientos, los softwares de Bitcoin en competencia forjan planes a largo plazo

Las divisiones en el actual debate sobre el tamaño de los bloques se hicieron más pronunciadas esta semana después de una conferencia privada y un aumento en la actividad de la red que vio a los usuarios esperar más y pagar más para confirmar las transacciones.

El debate en curso sobre cómo se debe escalar la cadena de bloques de Bitcoin para dar cabida a nuevos usuarios fue, según se informa, un punto de atención en los recientesMesa redonda de Satoshi, un retiro al que solo se podía asistir con invitación que unió a desarrolladores y líderes empresariales. Sin embargo, las señales sugieren que los asistentes salieron del evento con unmás negativovisión del estado del discurso.

Pero incluso mientras persisten las tensiones, el desarrollo de ambas versiones en competencia del software de Bitcoin – Bitcoin clásico y CORE de Bitcoin– continúa mientras los grupos presionan para obtener el apoyo de la base más amplia de usuarios de la red.

A fines de febrero, Bitcoin CORE, el grupo de desarrolladores más grande y con mayor trayectoria de la red, lanzó una nuevahoja de ruta, y junto con él, el último lanzamiento: la versión0.12.0– del software.

Poco después, el equipo detrásLa implementación alternativa de Bitcoin Bitcoin Classic anunció su hoja de ruta para 2016 <a href="https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md">https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md</a> , y esta semana siguió con el lanzamiento de la última versión de Classic, basada en la versión CORE 0.12.0.

Los lanzamientos siguen siendo de interés para la comunidad, ya que cuando se trata de una posible bifurcación de Bitcoin , el resultado puede ser que el ganador se lo lleve todo.

Los principales tecnólogos creen que el grupo que pueda llegar a un consenso en torno a su visión verá rápidamente sus conjuntos de reglas promulgadas y que, a pesar de las preocupaciones, el riesgo de que la red se divida en dos versiones incompatibles de la cadena de bloques sigue siendo bajo.

El director ejecutivo de Bloq, Jeff Garzik, le dijo a CoinDesk:

"La red Síguenos rápidamente la bifurcación ganadora, [hay] miles de millones en incentivos".

Este artículo LOOKS la composición de estos dos lanzamientos y cómo ambos grupos están avanzando para implementar su visión para la red Bitcoin .

Hoja de ruta clásica

En su hoja de ruta oficial de 2016, el equipo de desarrollo responsable de Classic publicó el plan previsto para implementar el software durante los próximos 11 meses.

Durante la primera fase, el equipo espera implementar BIP 109, originalmente propuesto para CORE por el desarrollador Gavin Andresen, que aumentaría el tamaño de los bloques de transacciones en la red Bitcoin del actual 1 megabyte (MB) por bloque a 2 MB por bloque.

El umbral para esta transición se alcanzaría cuando se minaran 751 de los 1000 bloques anteriores, con el código compatible con bloques mayores. Al alcanzar ese umbral del 75 %, comenzaría un período de activación de 28 días.

Andresen le dijo a CoinDesk:

El peligro de un umbral alto es que un minero o un operador de pool pueda verse obligado a ejercer ese veto; podrían ser amenazados o chantajeados. Este no es un riesgo teórico. Vemos ataques de denegación de servicio contra pools o servicios que "votan en sentido contrario", e incluso se han reportado amenazas de muerte.

El período de 28 días ha preocupado a algunos en la comunidad, pero Andresen comentó en un recienteentrada de blog que "varios de los principales mineros de Bitcoin , intercambios [y] proveedores de billeteras web" han indicado que el período de activación les da "tiempo de sobra" para cambiar su software.

Defendió además el período de gracia de 28 días comparándolo con la última actualización de la versión de bloque.

Andresen explicó que tomó aproximadamente un mes alcanzar el 75% del hashrate y una vez que eso sucedió, solo tomó otros siete días para alcanzar el 95% del hashrate.

En otras palabras, cree que no parece haber una preocupación significativa con respecto a una ventana de transición de 28 días.

Fases futuras del Clásico

En el caso de que comience la bifurcación dura, Classic entrará en su segunda fase durante el segundo o tercer trimestre de 2016 con el objetivo de abordar las preocupaciones sobre el tamaño de los bloques.

El objetivo de la segunda fase es eliminar las barreras técnicas (debidas a un protocolo de red ineficiente) que limitan la capacidad de la red. En lugar de transmitir una gran cantidad de datos al encontrar un nuevo bloque, se transmitirá una pequeña cantidad de datos, haciendo referencia a datos de transacciones que ya deben haberse transmitido, explicó Andresen.

Continuó afirmando que estas eficiencias no son una preocupación en bloques de 1 MB o 2 MB, pero que el objetivo final de la segunda fase era "detener la toma de decisiones centralizada sobre el tamaño máximo 'correcto' y volver a la visión original de Satoshi de un sistema autorregulado".

El paso final del equipo Classic es introducir un límite de tamaño de bloque dinámico, pero solo después de que "los mineros y las empresas confirmen que la fase dos abordó con éxito sus preocupaciones sobre el tamaño de bloque".

Una propuesta presentada en la hoja de ruta es utilizar una variación del tamaño de bloque adaptablebasado en el tamaño de bloque medio reciente descrito en una publicación de blog reciente de Stephen Pair, director ejecutivo de BitPay.

"Para determinar el límite del tamaño de bloque, se calcula el tamaño de bloque medio sobre una muestra reciente de bloques y se aplica un múltiplo", escribió Pair.

Pair continúa explicando que, a diferencia del tamaño promedio de bloque, la mediana es mucho más difícil de manipular. Con un tamaño promedio de bloque, los mineros podrían inflar el tamaño del bloque con sus propias transacciones o, por otro lado, no incluir transacciones en los bloques. Con la mediana, se necesitaría una acción coordinada de más del 50% de la capacidad minera.

Por supuesto, si alguien controlara más del 50% de la capacidad minera, Bitcoin tendría que afrontar problemas más grandes que el límite del tamaño del bloque.

Junto con un aumento en el tamaño del bloque, Classic planea realizar una conferencia "donde estas y futuras soluciones y preocupaciones de escalamiento se puedan discutir entre la comunidad".

La nueva versión, publicada el 7 de marzo, incorpora elementos de la versión 0.12.0 de Bitcoin Core pero, en particular, deja deshabilitada de forma predeterminada la función de reemplazo por tarifa (RBF), con la que los usuarios pueden retransmitir transacciones con tarifas más altas siempre que no se hayan incluido en un bloque.

CORE lanza la última versión del software

El Equipo de desarrollo CORE anunció el lanzamiento de la versión v0.12.0 el 23 de febrero, que los desarrolladores describieron como potencialmente "la más ONE hasta ahora, con mejoras más significativas que cualquier otra anterior".

El equipo diseñó el lanzamiento para optimizar el rendimiento general del software. En muchos casos, su objetivo era reducir los recursos computacionales necesarios o acelerar la ejecución de las acciones.

En noviembre de 2015, el desarrollador CORE Pieter Wuille presentó una Request de extracciónpara cambiar a una validación ECDSA basada en libsecp256k1. En él, explicó que dicha transición traería tres beneficios.

"La validación de firmas es entre 2,5 y 5,5 veces más rápida; el código de consenso ya no depende de OpenSSL ni de su analizador de firmas; elimina la vinculación con OpenSSL desde libconsensus", escribió.

Dejar de utilizar OpenSSL también tuvo implicaciones de seguridad.

"OpenSSL es muy completo en sus capacidades, pero este enorme conjunto de características significa que su superficie de ataque es bastante grande como resultado", escribió el equipo en su anuncio v.0.12.0.

Tras casi tres años de desarrollo, libsecp256k1 se ha fusionado con el cliente Bitcoin CORE , lo que, según el equipo, ha resultado en una mejora de siete veces en la velocidad de validación de firmas. Además, dado que libsecp256k1 se centra principalmente en la validación de firmas, el riesgo de vulnerabilidades de seguridad es mucho menor, según CORE.

Continuando con su optimización, el equipo también implementó un mecanismo para evitar fallas en los nodos debido a los límites del grupo de memoria.

Otro cambio clave tiene que ver con cómo los nodos almacenan las transacciones que aún no han llegado a un nuevo bloque.

En una entrada de blog publicada antes de que éldejó el equipo de Bitcoin COREEl desarrollador Mike Hearn advirtió sobreel potencialpara una disminución significativa en los nodos de la red.

A medida que se realizan transacciones, estas ingresan al conjunto de memoria, donde se almacenan hasta que se muestran en la cadena de bloques. A medida que se producen más transacciones, se introducen más en el conjunto de memoria. Para los nodos con mucha memoria, esto no representa un problema; sin embargo, aquellos que operan con cantidades mínimas de memoria se enfrentan a una situación potencialmente peligrosa.

Hearn esbozó tres posibles escenarios que podrían surgir de esta circunstancia:

El nodo podría volverse increíblemente lento al entrar en el infierno de intercambio; podría bloquearse al intentar asignar memoria y fallar; el kernel del sistema operativo podría eliminarlo.

Para contrarrestar esto, CORE introdujo una función llamada limitación del grupo de memoria, que establece un límite estricto predeterminado para el tamaño del grupo de memoria; específicamente, está establecido en 300 MB en 0.12.0.

Lo que sucede efectivamente es que, a medida que un nodo comienza a recoger más transacciones, si el grupo de memoria alcanza ese límite de 300 MB, el nodo primero descartará las transacciones que ofrecen la tarifa más baja por byte en lugar de simplemente aceptar más transacciones.

Reducción de los costes de recursos

La versión 0.12.0 también introduce un factor limitante para el tráfico de carga. Dado que los nodos retransmiten constantemente transacciones en la red, esto puede resultar en un aumento en la cantidad de recursos de carga, lo que supone una carga para los nodos individuales.

Un factor de limitación del tráfico de carga permite al operador limitar la cantidad de datos que se cargan y comparten con el resto de la red Bitcoin . Si se alcanza este límite, el nodo servirá los bloques solicitados durante la última semana, minimizando así la necesidad de recursos.

Para evitar aún más que los nodos se saturen, el equipo introdujo la poda de billeteras.

Actualmente, los nodos almacenan una copia completa de la cadena de bloques. Al momento de escribir este artículo, esto significa que cada nodo necesita almacenar 57,8 GB de datos de transacciones. Cuanto mayor sea esta capacidad, mayor será el espacio de almacenamiento necesario.

El nuevo "modo podado" permite a quienes usan la billetera Bitcoin CORE reducir el espacio en disco requerido de 60 GB a solo 2 GB.

"Esto significa que el nodo solo se centrará en realizar el seguimiento de las salidas no gastadas y olvidará los bloques procesados previamente, así como las salidas que se han gastado", explicó el equipo.

Si bien hubo controversia con elinclusión de la sustitución por tarifaFundamentalmente, la nueva versión se centró en hacer que el funcionamiento de los nodos requiera menos recursos.

Como elnúmero de nodos Ha disminuido en los últimos años, por lo que la reducción de los recursos necesarios debería llevar a que más usuarios opten por ejecutar nodos que validen completamente la cadena de bloques. Cuantos más nodos haya en la red, más seguro será Bitcoin .

Imagen de un excursionista perdidovía Shutterstock