El drama detrás de las actualizaciones de una blockchain

0

Las actualizaciones de una cadena de bloques pública, como Bitcoin o Ethereum, siempre representan fuertes dolores de cabeza. Pero, ¿cumplen su objetivo final?

Ethereum implementaría su próxima gran actualización, Constantinopla, a mediados de enero de 2019. Sin embargo, no fue posible, debido a que descubrieron un error importante en el código a último momento. Incluso, hubo nodos que ya habían actualizado la nueva versión.

Constantinopla consideraba muchas mejoras de rendimiento, incluída la que más tiempo tomó en llegar a un acuerdo: la modificación en la bomba de dificultad. Los desarrolladores de Ethereum quieren migrar de PoW a PoS, por lo que buscan alentar a los participantes de la red a través de una serie de bombas predefinidas que irán reduciendo la recompensa por cada bloque creado. Finalmente, se actualizará el software que gobierna a esta cadena de bloques.

Mira también: Bomba de dificultad alteraría política monetaria de Ethereum

Aún no se ha definido precisamente la nueva fecha de actualización. Ahora, además, muchos desarrolladores primarios de Ethereum han propuesto que su nombre sea Estambul, en lugar de Constantinopla.

La complejidad detrás de las actualizaciones de una blockchain

Una de las características de las organizaciones descentralizadas es la ausencia de una autoridad central que tome las decisiones a nombre de sus subordinados. Por lo tanto, nadie determina realmente cómo opera la red. Las cadenas de bloques tienen reglas establecidas a través de un protocolo o algoritmo de consenso y se definen en el código que establece su funcionamiento.

Por lo tanto, los participantes de una blockchain —individuos, empresas o mineros— cumplen con las reglas de consenso. Están conscientes de que cualquier cambio en la red que se proponga requiere, en teoría, de una coordinación entre todos sus participantes que, en la mayoría de los casos, no se conocen entre sí.

En las cadenas de bloques realmente descentralizadas, los cambios más o menos ocurren de esta manera:

  1. Si uno de los participantes tiene una idea que quisiera implementar para mejorar las características de la red, habla con otros participantes al respecto. Si su idea tiene aceptación, escribe una propuesta formal —por ejemplo, una propuesta de mejora de Bitcoin (BIP)—.
  2. Dicha propuesta se comparte en los diferentes canales digitales, como listas de correo o foros, en los que participan miembros de la comunidad.
  3. Si se considera que la propuesta es una buena idea, el trabajo empieza, generalmente, con planes para implementarla con otras mejoras similares. Las actualizaciones compatibles con versiones anteriores del software pueden implementarse —muy lentamente— como una bifurcación suave. Los cambios más grandes que no son compatibles con la versión actual, deben implementarse obligatoriamente a través de una bifurcación dura. Usualmente, la implementación de este proceso es muy polémico y muchos usuarios que no están de acuerdo deciden seguir usando la versión anterior del software y, eventualmente, crear una nueva cadena de bloques.
  4. Cada implementación de software se actualiza por separado. Se anuncia la fecha de actualización con la debida anticipación para que todos los nodos tengan el tiempo suficiente de actualizar a la versión más reciente del software. Llegada la fecha de actualización, se activan las nuevas características de la implementación.

Mira también: Explicación acerca de las bifurcaciones de una blockchain

Un ejemplo de cuánto tiempo toma este proceso es la implementación de SegWit en la blockchain de Bitcoin. Pasaron dos años de un serio y acalorado debate, porque las bifurcaciones duras son el último recurso en Bitcoin. Finalmente, SegWit se adoptó mediante una bifurcación suave, después de que Peter Wuielle —desarrollador primario de Bitcoin y cofundador de Blockstream— descubrió la manera de hacerlo.

La ruptura consenso en Ethereum y su impacto

La investigación y desarrollo de PoS ha tardado más de lo esperado, por lo que los desarrolladores de Ethereum necesitaban impulsar la implementación de la bomba de dificultad. Al mismo tiempo, requerían que los mineros permanezcan a bordo y no abandonen la red.

No obstante, cuando casi el 50% de los nodos ya se había actualizado al nuevo software, una empresa independiente de auditoría de seguridad de contratos inteligentes, ChainSecurity, encontró una vulnerabilidad. Esto obligó a que la actualización se posponga hasta febrero.

El debate revivió porque los programadores de contratos inteligentes —como no puede ser de otra manera— quieren que sus códigos sean inmutables, tal y como Ethereum garantizó en un inicio. Explican que la forma en la que se interpreta el código a través de las nuevas actualizaciones podría afectar significativamente esta propiedad.

Del mismo modo, este debate se ha extendido hacia la comunidad criptográfica. Dice que hacer cambios en una cadena de bloques es más parecido a la ciencia espacial que a la creación de una aplicación para compartir fotos. Los errores pueden ser fatales e incluso más difíciles de corregir luego de la ejecución de las implementaciones.

¿Qué garantías deben dar los desarrolladores de los protocolos a quienes crean aplicaciones en la parte superior de su cadena? ¿Es posible que un pequeño grupo de desarrolladores o algunas empresas tengan el control sobre la hoja de ruta de Ethereum?

Es indiscutible que las blockchain públicas enfrentan complejos problemas de escalabilidad, teniendo en cuenta que dependen del acuerdo entre sus participantes. Las cadenas de bloques públicas sacrifican la toma eficiente de decisiones en favor de la autonomía y el empoderamiento que se logran a través del consenso generalizado. Aún estamos lejos de descubrir si esta visión que pretende modificar radicalmente el paradigma del orden social y modificar el balance de poder tendrá éxito.

¿Te gustó el artículo? ¡Puedes apoyar a Juan Francisco Bolaños en Patreon!

Deje un Comentario

Su correo electrónico no será publicado.