Los programadores de Bitcoin se enfrentan a un viejo dilema: cómo actualizar una red completa

Un viejo debate está resurgiendo en la comunidad de desarrolladores de Bitcoin , subrayando ONE de los desafíos críticos que enfrentan los sistemas descentralizados: cómo actualizar el software cuando aparentemente nadie está a cargo.

El catalizador en esta ocasión se llama Taproot/Schnorr, una actualización de Privacidad y escalabilidad que se ha estado desarrollando durante años y que se ha visto progreso emocionante Recientemente, especialmente ahora que se está revisando y probando el código en forma de "pull Request", acercando a la realidad un cambio que se discutió por primera vez hace años.

El cambio de código en sí no ha generado controversia entre los desarrolladores hasta el momento. ¿Qué? esEl debate es la mejor manera de activar el cambio, haciendo finalmente posible el envíoBitcoin (BTC) transacciones de esta nueva manera.

La razón principal por la que surge esta pregunta es que Bitcoin no tiene un líder y está distribuido por todo el mundo. ¿Cómo se actualiza toda la red de forma fluida y compatible con versiones anteriores, permitiendo que quienes tengan versiones anteriores del software sigan participando? ¿Cuál es la mejor manera de que Bitcoin realice este tipo de cambio sin interrupciones?

Para que quede claro: el código de Bitcoin se actualiza.casi todos los díasPor la red global de desarrolladores del proyecto de código abierto. Pero los cambios de código "consensuados", que afectan a una parte más profunda de Bitcoin, requieren una "bifurcación suave", que a su vez requiere cierta coordinación para su correcta implementación.

Hay una serie de diseños de bifurcación suave que recientemente han avanzado considerablemente hacia su implementación y futura adopción. Sin embargo, por diversas razones, los métodos de activación... han recibido poca atención.CORE de BitcoinEl colaborador Matt Corallo escribió enun correo electrónico a la lista de desarrolladores de Bitcoin el mes pasado que reabrió el debate.

Hay dos opciones principales para implementar una bifurcación suave. Una opción, la Propuesta de Mejora de Bitcoin (BIP) 9, se ha utilizado en algunas bifurcaciones suaves en el pasado. Esta garantiza... minerosSe preparan con antelación a una bifurcación suave para garantizar que el cambio se propague sin problemas por toda la red. Una objeción frecuente a este enfoque es que otorga demasiado poder a los mineros.

Como alternativa, existe BIP 8, también conocida como bifurcación suave activada por el usuario (UASF), que se activa independientemente de si los mineros indican que están listos o no. Según la ejecución, este enfoque podría causar otros problemas, advirtió Corallo.

Lección de historia

El debate comenzó en 2017, cuando se utilizó BIP 9 para activar Segregated Witness, o SegWit, un cambio fundamental en el gran debate sobre la escalabilidad de Bitcoin. Para proteger a los mineros de minar bloques inválidos y perder dinero, SegWit no se activaría hasta que el 95 % de los mineros indicara que estaban listos.

La mayoría de los pools de minería (grupos de mineros que combinan su potencia computacional en la red) declararon que no respaldarían SegWit —en esencia, lo vetarían— a menos que se combinara con un aumento en el tamaño del bloque. (El misterioso creador de Bitcoin había establecido el límite en 1 megabyte, lo que limitaba la cantidad de transacciones que se podían almacenar en bloques, que se publican aproximadamente cada 10 minutos).

Esta fue una demanda controvertida que muchos creían que podría conducir a la centralización de la red (y que, de todos modos, no podría ejecutarse con éxito a menos que Bitcoin estuviera centralizado).

En pocas palabras, el incidente demostró que los pools de minería podrían usar el umbral del 95 por ciento para extraer otros cambios en lugar del propósito previsto: ayudarlos a adaptarse al cambio para no perder dinero.

A muchos usuarios de Bitcoin no les gustó esto, pues lo vieron como un intento de los mineros de usar su poder para impulsar un cambio que no todos los usuarios querían.

Mientras este debate se intensificaba, un misterioso desarrollador, conocido como Shaolinfry, señaló que los usuarios de bitcoin aún podían realizar la actualización. La idea principal es que los usuarios y las plataformas de intercambio de Bitcoin decidan si un cambio se implementa, y los mineros Síguenos sus deseos, no al revés. Este método se había utilizado para activar otros cambios en Bitcoin . Shaolinfy formalizó esta idea en BIP 8, también conocido como UASF.

Un gran número de usuarios declaró abiertamente su apoyo a SegWit UASF en redes sociales y comenzaron a ejecutar el software. Esto pareció surtir el efecto deseado. Antes del día de la activación de UASF, los mineros comenzaron a manifestar su apoyo a SegWit.

Cabe destacar que circularon un par de versiones de UASF durante esta época turbulenta, una más cautelosa (y con un calendario más conservador) y menos controvertida que la otra. Sin entrar en detalles, la conclusión para algunos desarrolladores de Bitcoin fue que UASF era una mejor manera de implementar cambios.

En ese momento, Rusty Russell, un desarrollador de la startup de Bitcoin Blockstream, llegó al punto de disculparse por participar en la construcción de BIP 9.

"No esperaba que este punto de control se utilizara como punto de estrangulamiento para extorsionar la red. Esto cambia significativamente el modelo de riesgo;BIP-8"Ahora es un método muy superior para las actualizaciones de red, donde los mineros solo pueden acelerar el proceso, no bloquearlo", escribió en un Medium.correo.

Largos recuerdos

Al recordar todo este drama, algunos desarrolladores se muestran cautelosos a la hora de volver a utilizar BIP 9 para Schnorr/Taproot u otros cambios futuros.

"Creo que el BIP 9 es un fracaso demostrado",dicho CORE de Bitcoin El desarrollador Luke Dashjr, en respuesta a Corallo, explicó las razones técnicas de su objeción. Durante el debate sobre el escalado, Dashjr fue ONE de los defensores más enérgicos de un UASF para impulsar SegWit.

Alex Bosworth, un desarrollador de la startup Lightning Labs, expresó una Opinión similar, basada en parte en el drama reciente en torno a Bitcoin Cash (BCH), una Criptomonedas más pequeña que se separó de Bitcoin en 2017.

Un grupo considerable de grupos de minería de Bitcoin Cash recientementepropuestoque una parte de BCH de cada nuevo bloque debería ir a un fondo de desarrollo, lo que Bosworth ve como otro ejemplo de cómo los grupos de minería hacen alarde de su poder de una manera que es mala para la descentralización de las Criptomonedas .

Sé que la idea común para implementar una bifurcación suave es intentar el método tradicional de minería amigable. Pero un buen [un tercio] de nuestra tasa de hash actual se ha organizado en un cártel con el propósito de censurar y robar el subsidio de las monedas. tuiteóBosworth, que trabaja en la infraestructura para la red de rayos rápida y escalable.

Por eso apoya un método UASF, aunque con un horizonte temporal más largo.

"Me parece que lo más apropiado es un UASF de combustión lenta", añadió.

Síntesis

Pero algunos, instando a la cautela, se preocupan de que considerar los UASF como el único método de activación podría abrir la posibilidad de impulsar cambios que podrían perjudicar a Bitcoin.

Por ejemplo, una de las razones por las que a los desarrolladores les gustó inicialmente BIP 9 es que el umbral del 95 % podía proporcionar una especie de red de seguridad. Si se detectaba un problema mientras los grupos de minería actualizaban su software, estos podían detener el cambio. Es más difícil detener la activación de UASF una vez iniciada.

Por eso Corallo volvió a proponer una idea antigua, una especie de mezcla entre BIP 8 y BIP 9. La bifurcación suave comenzaría con BIP 9. Si fracasaba en el transcurso de un año debido a objeciones irrazonables, los usuarios podrían debatir y reagruparse durante seis meses. Después, si el cambio es definitivamente algo que la comunidad desea, podrían probar BIP 8 durante otro año.

Algunos desarrolladores podrían argumentar que este plazo es demasiado largo para un cambio sin objeciones irrazonables. Pero Corallo pidió paciencia.

Descubrir si las objeciones son realmente irrazonables podría llevar tiempo. "En caso de que fracase, el proceso BIP 9, de hecho, ofrece una buena oportunidad de aprendizaje sobre el nivel de preparación y el deseo de la comunidad para un cambio determinado", afirmó.

"Desarrollar Bitcoin no es una carrera. Si es necesario, esperar 42 meses garantiza que no sentemos un precedente negativo del que luego nos arrepentiremos a medida que Bitcoin siga creciendo", afirmó. Los lectores pueden leer el razonamiento completo de Corallo, así como muchas de las respuestas matizadas de los desarrolladores. aquí.

Y aunque Russell parecía bastante en contra de BIP 9 en 2017, le dijo a CoinDesk que ahora está de acuerdo con este enfoque híbrido.

"Dado que el intento de los mineros de bloquear los cambios no funcionó, y no sufrimos mucho por el retraso, no me importa la activación de BIP-9", dijo. Pero propuso un plazo más corto que el de Corallo.

"Quizás el plazo de un año para el BIP-9 sea demasiado largo, y sería preferible uno de seis meses. De esta manera, los usuarios pueden organizar una UASF si la activación del BIP-9 falla y consideran que se debe al obstruccionismo de los mineros", dijo Russell.

Los ingenieros están revisando minuciosamente el código propuesto para Taproot/Schnorr para solucionar cualquier problema persistente. Por lo tanto, aún hay tiempo para que los desarrolladores discutan las opciones de activación. Sin embargo, la comunidad deberá tomar una decisión antes de que el cambio pueda implementarse en Bitcoin, lo que aportará mayor Privacidad a la red.