El Proceso de Fusión Bitcoin Core
Un importante punto de confusión, especialmente entre personas que no tienen mucha experiencia trabajando en desarrollo de software open source, es cómo Bitcoin Core realiza cambios a su código. A continuación, he adaptado un post previamente hecho como respuesta a otro artículo, puesto que pienso que este tema merece su propio posteo.
El acceso commit, la habilidad de agregar nuevos commits a la base de datos de Bitcoin Core, es un rol de mantenimiento… el cual se asegura de que el repositorio no sea vandalizado y que sólo los commits que tienen amplio apoyo o, son muy sencillos, sean fusionados. Es una idea errónea aquella que dice que sólo las personas con acceso commit son capaces de hacer cambios en un código. Fusionar los cambios es tan sólo el último paso de un largo proceso. Las personas con acceso commit son llamadas mantenedores.
Si un mantenedor fuese a empezar a fusionar cosas irresponsablemente, otros desarrolladores podrían insistir en revocar su acceso commit o bifurcar el proyecto a un repositorio separado, consiguiendo que distintos desarrolladores se unan a este otro, donde el acceso commit puede ser reasignado de la manera que quieran.
Cualquiera puede bifurcar el repositorio de código de base y hacer cambios arbitrarios a su propio repositorio. Podría incluso construir un cliente desde su propio repositorio y ejecutarlo si eso es lo que quiere. También podría hacer construcciones binarias para que otras personas las ejecuten.
Si alguien quisiera fusionar un cambio que haya hecho en su propio repositorio en la Bitcoin Core, puede presentar una solicitud de retiro. Una vez presentada, cualquiera puede revisar los cambios y comentar en ellos, sin importar si tienen o no acceso commit a Bitcoin Core.
Otros incluso pueden clonar el repositorio local y compilar y ejecutar el programa con los cambios por sí mismos en su propia máquina, o hacer modificaciones adicionales y presentarlas como propuestas. Estas propuestas también pueden ser discutidas. Estas discusiones a menudo se extienden por días, a veces incluso semanas o meses (especialmente cuando se trata de cambios críticos de seguridad o consenso), con el autor original recibiendo sugerencias de colegas y haciendo cambios y correcciones.
Sólo una vez que no quedan más objeciones razonables será que un mantenedor fusionará el código.
Los mantenedores habrán de pasar por exactamente el mismo proceso de revisión de pares que cualquier otra persona al presentar sus propuestas. Deberán también bifurcar el repositorio del código base y hacer los cambios propuestos en su propia copia. Deberán presentar una solicitud de retiro antes de fusionar cualquier cambio no trivial y someterse a una revisión por parte de los demás. Fusionar cualquier cambio no trivial sin la revisión externa es una violación al proceso y podría resultar en el retiro del acceso commit del mantenedor.
Los cambios de consenso van mucho más allá de los cambios de código. Existen dos tipos básicos de cambios de código: bifurcaciones duras y suaves. Las bifurcaciones duras pueden resultar en una rotura de cadena, en la que distintos nodos terminan en cadenas separadas y verán un libro distinto, a no ser que todos los nodos en la red sean actualizados. Las bifurcaciones suaves no resultan en una rotura de cadena, siempre y cuando estén apoyadas por el suficiente hashpower, ya que esto asegurará que todos los nodos converjan al final en la cadena con la mayor prueba de trabajo.
A pesar que una cadena cuenta con más hashpower que la otra en el momento de la bifurcación, todavía puede ser superada en hashpower más adelante. Las bifurcaciones duras y suaves pueden ser aún más subdivididas entre distintas clases, dependiendo de su comportamiento en estas situaciones.
Para poder hacer un cambio de consenso, no sólo es necesario fusionar el código en el repositorio – también se necesita tener a otras personas en la red para ejecutar ese código. Bitcoin Core, como proyecto, ha sido generalmente conservador cuando se trata de este tipo de cambios. Tales cambios requieren un profundo entendimiento no sólo del protocolo, sino de la teoría de juego y políticas también, particularmente si un cambio tiene posibilidades de provocar que distintos jugadores tengan intereses divergentes.
Los cambios de consenso con probabilidad de causar intereses divergentes casi siempre son evitados. Asegurar que un cambio de consenso no cause intereses divergentes es, en general, un problema extremadamente difícil, incluso para grandes expertos quienes a veces se equivocan. Cualquier introducción de una incompatibilidad es responsable de crear intereses divergentes en la red y por lo tanto, no deberá ser tomada a la ligera.
Fuente: https://medium.com/@elombrozo/the-bitcoin-core-merge-process-74687a09d81d