Estudio de caso: manejo de bifurcaciones o forks en una Altcoin

Por considerar que el uso de los blockchains es un medio promisorio de intercambio en las criptomonedas, pero también en las bases de datos y en lo que podríamos definir como inventario fluido social, nos permitimos ofrecer la traducción de la experiencia de la altcoin estrella y consentida en Reddit: el dogecoin. El germano J Ross Nicoll es uno de los principales desarrolladores de esta criptomoneda. [CM].

Por J. Ross Nicoll

[Original: Case Study: Forking a Major Altcoin]

1 Resumen

Desde que se creó en diciembre del 2013, la criptomoneda Dogecoin ha experimentado varias derivaciones o bifurcaciones (forks) de su cadena de bloques (blockchain), dos de esos casos fueron deliberados. En este documento se describe el proceso de bifurcación y sus riesgos, a la vez que se analizan los antecedentes que llevaron a la cuarta bifurcación, se realizan observaciones sobre cómo fueron ejecutadas y se explorará el proceso seguido para minimizar cualquier posible disfunción. Concluiré con un resumen de los procesos y con observaciones para eventuales bifurcaciones futuras del blockchain. Como en lo general el proceso de bifurcación no fue pensado como un experimento, es obvio que se cuenta con datos limitados.

Este documento está dirigido a aquellas comunidades consultoras en criptomonedas. Deseablemente, los lectores deberán estar familiarizados con la terminología de las criptomonedas, no obstante que carezcan de un conocimiento técnico profundo.

 

2 Antecedentes

Los detalles están más allá del alcance de este documento, pero en verano 2014 los principales colaboradores del Core (núcleo) del monedero Dogecoin llegaron a la conclusión de que el curso que llevaba el proceso de minería no era sustentable, y que la prueba de trabajo (proof of work), que había sido diseñada para cadenas de bloque (blockchain) de otras monedas Scrypt, no debía ser empleada para los bloques de Dogecoin (en referencia a la posibilidad de emplear la prueba de trabajo, también conocida como AuxPoW, que implicaba la fusión del proceso de minería con otra altcoin). Cada bloque de un blockchain del tipo Bitcoin contiene una dificultad predefinida (derivada de la tasa en que se van encontrando los bloques válidos), misma que define los criterios de hash procesados en la cabeza del bloque que deben reunirse para ser válidos.[5] El haber agregado la prueba de trabajo (AuxPoW) a Dogecoin pudo añadir un criterio alternativo, en el cual la tasa de hash procesados de la cabeza del bloque desde otra red pudo reunir la dificultad objetivo para formar un bloque válido, permitiendo que el mismo trabajo ejecutado pudiera ser útil para dos o más blockchains.[4]

En el momento en que esta prueba auxiliar de trabajo fue minada, la tasa de hash del bloque procesado pudo no haber reunido la dificultad esperada para el bloque, y pudo haber sido rechazada por algunos clientes, los cuales tuvieron problemas para soportar el cambio. Esto pudo haber ocurrido incluso con los clientes actualizados para aceptar el bloque, mientras que otros no tuvieron problema, y ningún minero que utilizó un cliente antiguo pudo continuar minando como antes bloques válidos. Una vez que se encontraba un bloque, y éste era transmitido a la red, podría teóricamente reemplazar bloques desde la nueva cadena si la tasa de hash procesados era numéricamente inferior a la del bloque de la nueva cadena.

Sin embargo, al colocar los mineros el enfoque en el esfuerzo de la nueva cadena, el trabajo computacional realizado para minar esa cadena deberá ser consistentemente mayor que la cadena anterior. El software del wallet (monedero) utiliza la cadena válida con la mayor parte del trabajo realizado (textual: «la mejor cabecera de la cadena[1]), y como tal, los clientes que apoyan la nueva cadena no tendrá en cuenta todos los bloques después del punto de bifurcación, y la verán como si se tratara de una cadena inferior. Por lo tanto, los clientes anteriores siguen construyendo en la cadena anterior, mientras que los nuevos clientes continúan en su nueva cadena. Es en este punto cuando se dice debe hacerse una bifurcación del blockchain.

Siempre será deseable minimizar el impacto de esta bifurcación, ya que puede conducir a dos idénticas criptomonedas, aunque incompatibles. Por consiguiente, era imperativo que el mayor número de usuarios emplearan clientes con las mismas reglas de consenso, idealmente las normas la actualización ya con el soporte de AuxPoW. El software del cliente para Dogecoin es administrado principalmente por un solo grupo de desarrolladores, lo que simplifica la tarea de garantizar que todos los clientes tengan versiones que pudieran sostener el AuxPoW. Las tareas restantes eran más bien de difusión, para asegurar que los usuarios estuvieran al tanto de la actualización, y minimizaran las interrupciones durante el proceso de bifurcación.

 

3 Metodología

Se decidió que, dada la urgencia de la actualización, equilibrada con el alto número de usuarios para notificar, los bloques de AuxPoW debían ser aceptados en alrededor de 6 semanas después de la confirmación inicial de la modificación. Para simplificar el consenso sobre cuándo el cambio habría de ocurrir, un punto de referencia fue el tamaño del bloque en lugar de la hora del reloj público, para evitar cualquier interrupción potencial debido a las inconsistencias del reloj en consenso. El bloque 371,337 fue elegido con una fecha estimada (el 10 de septiembre de 2014). El anuncio inicial del cambio se hizo el 3 de agosto 2014[3], y fue anunciado a través de reddit, BitcoinTalk, IRC, los foros Dogecoin, y transmitida a través de los principales medios de noticias de las criptomonedas.

Cuatro tareas principales fueron identificadas con atención, con el fin de minimizar las cualquier irrupción, y garantizar la mejor oportunidad posible para que la bifurcación tuviera éxito. Estas tareas fueron:

• Difusión de información previa a la bifurcación
• Coherencia de la red durante y después de la bifurcación
• Recuperación de monederos individuales que estaban en el mal forma
• Planes de contingencia en caso de una falla mayor

 

3.1 Difusión

Con el fin de evaluar y gestionar el riesgo de transición, se recopiló una lista de los principales servicios y sus datos de contacto. Cada uno de ellos fue contactado, utilizando el método del servicio preferido de contacto especificado (correo electrónico, formulario web, canales IRC), cuando así se especificaba. El contacto fue registrado para indicar cuándo se hizo y por quién se hizo. Si había un servicio confirmado de contacto, y también registrado, se especificaba por quién fue recibido. Si había un servicio confirmado (al mismo tiempo o posterior) el cual había actualizado el monedero, también se registraba. Los servicios que fueron considerados de alto impacto (por ejemplo, los intercambios, los procesadores de pago) fueron contactados al menos una vez más, si no habían confirmado la actualización.

Significativamente, más de 200 servicios fueron contactados en total. Para gestionar la logística de este ejercicio, el estado de los contactos fueron almacenados en una hoja de cálculo compartida «Google Docs», que los voluntarios podían editar colaborativamente. Los servicios fueron agrupados libremente en categorías de la siguiente manera:

• Servicios de alto impacto
• Donantes
• Intercambios
• Grifos o Faucets
• Los sitios de juegos
• Comerciantes
• Piscinas de minería
• Procesadores de Pago
• Propinas o Tip bots
• Monederos

Un pequeño número de servicios volvió a indicar problemas con la actualización, debido a personalizaciones previas en el software y a los sistemas operativos/hardware  no estándares, entre otros. El equipo de desarrollo atendió los requerimientos siempre que fue posible, proporcionando asesoramiento y asistencia con parches cuando fue necesario, para fomentar la adopción rápida.

3.2 Red de Coherencia

En segundo lugar, para asegurar el proceso de bifurcación sin causar alguna mínima interrupción a la red, un par de horas antes de la esperada bifurcación se pusieron en marcha un gran número de «nodos de refuerzo». Éstos corrieron una versión modificada del cliente, el cual empezó a disuadir conexiones desde el cliente pre  AuxPoW, mediante el uso de la versión mínima del protocolo. Como tales, los nodos de refuerzo encauzaron tantas conexiones como fue posible, en un intento de aislar nuevos nodos a partir de los viejos de la mejor manera posible.

Estos nodos se prepararon como el ejemplo de Amazon EC2, utilizando la capacidad de imagen de un servidor y lanzando un número de copias como «casos puntuales» con un gran rendimiento. Para minimizar el costo, la blockchain de cada nodo se retuvo en su instancia local (almacenamiento), en lugar de mantenerlos en el «Elastic Block Store». Una copia de la blockchain se había preparado antes de tiempo y se almacenó en el servicio de Amazon S3, y luego copiado hacia cada nodo como parte de la secuencia de arranque del nodo, minimizando el tiempo de sincronización inicial. Estos nodos se prepararon en diferentes zonas de Amazon EC2, para asegurar que siempre un nodo de baja latencia estuviera disponible en el mayor número posible de países.

3.3 Recuperación

Por último, se adoptaron medidas de mitigación para limitar los daños que pudieran producirse, en caso de presentarse algún problema. Las instrucciones sobre cómo recuperar los clientes en caso de algún problema, fueron publicadas ampliamente antes de la programada bifurcación, y repetidas varias veces durante las siguientes semanas, para asegurar que fueran fácilmente visibles. Se prestó especial atención a la difusión de los detalles de la bifurcación de Dogecoin, con el fin de identificar proactivamente algún problema que pudiera ocurrir en el proceso de actualización entre los proveedores de servicios.

3.4 Planificación de Contingencia

Un aspecto que afortunadamente no se requirió, fueron planes de contingencia en caso de que la actualización del código no pudiera ser adoptada. Pero vale decir, que durante el proceso de adopción se tenía también controlado a través de una combinación de nodos (Las versiones de cliente de los nodos que se conectaron a un nodo, se pueden recuperar a través del comando getpeerinfo comandos) y de BitInfoCharts (https://bitinfocharts.com/dogecoin/). Sin embargo, no está claro cómo BitInfoCharts mide versiones de cliente, por lo que en caso de que se diera alguna otra bifurcación en el futuro se recomienda una evaluación más controlada (ello también ofrecería la posibilidad de la captura de los datos, para su posterior análisis).

En caso de que las tasas de adopción se consideren demasiado bajas (no se especificó algún objetivo para la tasa de adopción), puede decirse que ello estuvo encaminado a posibilitar el contacto de cada servicio y sugerir un ritmo menor de adopción. Esto representaba sólo un último recurso, sin embargo, para contener alguna pérdida de confianza hacia los desarrolladores (quienes podrían haber quedado «flip-flop» entre dos versiones), y para reparar una eventual actualización fallida o un problema a resolver.

4 Resultado

El proceso para poner en contacto los servicios resultó un gran éxito, con sólo dos significativas observaciones. Dos intercambios, relativamente pequeños, no pudieron actualizarse a tiempo. Uno de ellos fue captado rápidamente debido a los usuarios que reportaron un problema en la recepción de monedas, y fue actualizado en 1-2 días. El segundo tomó mucho más tiempo para ser advertido, lamentablemente, por el cual un punto que había vendido cantidades significativas de Dogecoin proveniente de la cadena anterior, mismo que fue encontrado sin valor[2]. Los usuarios del intercambio fueron contactados, y cuando se les preguntó sobre su falta de actualización, afirmaron haber considerado como opcional la actualización, señalando que su sys-admin había estado indisponible durante la ventana de actualización.

No se realizó alguna medición sobre la eficacia de los nodos a impulsar, debido a que en ese momento no se consideró un valor significativo. Tampoco está claro cómo ello pudiera medirse sin una muestra de control. Un trabajo futuro podría incluir la evaluación de la eficacia a través de la simulación de la red. Dado el costo relativamente bajo de utilización, se sugiere que se aplique alguna evaluación en ejercicios futuros, a menos que haya razones para sospechar que ello resultará innecesario.
5 Conclusión

Haber tenido un equipo de gestión durante el proceso de bifurcación de la blockchain resultó un instrumento eficaz para minimizar cualquier disfunción, y es probable que haber tenido contacto directo con los proveedores de servicios haya mejorado el compromiso de todos con el proceso, tanto mediante la comunicación con los proveedores de servicios como con la garantía de apoyo a través del proceso. Para las criptomonedas ampliamente utilizadas, es evidente que una bifurcación de la blockchain es una empresa importante. Se recomienda que el periodo que transcurre desde el anuncio hasta la puesta en marcha de la bifurcación, sea el mayor tiempo posible.

Al tomar una postura activa en la gestión de estos procesos parece reducir sustancialmente la confusión entre los usuarios y contribuye a la transición, sin embargo sin un patrón de comparación sería difícil de evaluar.

Créditos

Me gustaría dar las gracias a «Langerhans» y «Sporklin» por su trabajo en Dogecoin. Langerhans ha sido clave en su papel de líder de desarrollo para el Dogecoin Core, el Multidoge y los Clientes de cartera para Android, así como ayudar en la notificación de los proveedores de servicios. «Sporklin» asumió el papel de la gestión de la comunidad, tanto en asistencia en la notificación como en la gestión de preguntas y comentarios de la comunidad, a través de un número de lugares.

También me gustaría dar las gracias a «TheRealMage» de la Asociación Litecoin, por su ayuda en el fomento de agrupaciones mineras Litecoin, al adoptar la fusión minera con Dogecoin. Sin ello, la transición probablemente habría sido mucho más difícil.

Por último, me gustaría agradecer a nuestros numerosos mineros leales, del cual yo estoy lamentablemente consciente de que el paso a AuxPoW se dio en condiciones de restricción. Todos ustedes son una garantía para Dogecoin, y quisiera decirles que la decisión de adoptar AuxPoW fue considerado un último recurso.

Licencia

Esta obra está bajo la licencia de: Creative Commons Attribution 4.0 License Internacional. Para ver una copia de esta licencia, visite http://creativecommons.org/licencias / por / 4.0 /.

 

Referencias

[1] Header Chain, Best Header Chain. https://bitcoin.org/en/ glossary/header-chain. Accessed 15 de Junio. 2015.

[2] Digiconomist. mcxNOW loses 350m DOGE, announces haircut. Octubre, 2014. Accessed 15 de Junio, 2015.

[3] Langerhans. Dogecoin to enable AuxPoW soon – all infos inside. https://www.reddit.com/r/dogecoin/comments/2ci90m/ dogecoin_to_enable_auxpow_soon_all_infos_inside/, August 2014. Accessed 15th June 2015.

[4] Merged mining specification. https://en.bitcoin.it/w/index.php? title=Merged_mining_specification&oldid=38827, 2013. Accessed 15th June 2015.

[5] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. http:// bitcoin.org/bitcoin.pdf, 2008.

[Traducción: Carlos Macías R.]