Un MASF es un mecanismo por el cual los mineros de la cadena de bloques pueden introducir nuevas actualizaciones sin que ello afecte su funcionamiento.
Un Miner Active Soft Fork (MASF) o bifurcación suave activada por minero es un mecanismo, que al igual que un UASF, genera un cambio o una transición de la red hacia un nuevo conjunto de reglas de consenso. La diferencia de MASF con UASF, es que el MASF es activado por los mineros usando su poder de hash en lugar de ser activado por los nodos completos.
Para la activación de este mecanismo, se requiere que los mineros expongan o revelen su disposición de aceptar los cambios o modificaciones al protocolo. Y para lograr esto, los mineros usan su poder de hash. Esto gracias a que los mineros realizan un cambio en los números de bits de versión de los bloques que minan. Entonces, para cuando se alcance una cierta cantidad de bloques minados con el cambio en los números de bits de versión, los nodos completos pueden hacer cumplir las nuevas reglas de consenso.
Un MASF es una bifurcación suave que depende de la señalización que realiza los mineros a través del poder de hash para activarla.
Implementación de un MASF en Bitcoin
La Propuesta de Mejora de Bitcoin (BIP) BIP 34, para la actualización y mejora de las transacciones y bloques versionados de la red, consigue un MASF en el protocolo. Donde los mineros sugieren su posición de aceptar o no los cambios propuestos en el consenso. Para esto, el cambio que posiblemente realizaría los mineros era poner un número mayor a 1 en el número de la versión del bloque; además de solicitar que el número de la altura de bloque se viera reflejado en la entrada de la transacción coinbase de cada uno de los bloques minados.
Entonces, para activar este mecanismo, los mineros deberían señalar el número de versión de bloque. Siendo “1” para las reglas antiguas, y el cambio de “1” a “2” para señalar la aceptación y transición a las nuevas reglas.
Por lo tanto, al implementar este mecanismo los mineros pueden optar por aceptar los cambios o no; es decir, optar por realizar la bifurcación o rechazarla. Entonces, en los últimos 1000 bloques generados por los mineros en la red, un 75% (que representan un total de 750 bloques) deben contener la señalización de la versión “1” a “2” para indicar que los cambios serían aplicados. Además, de que esos mismos 750 bloques pueden contener la altura del bloque indicado en la entrada de la transacción coinbase de cada bloque.
En este punto, los mineros que generan bloques con la versión “1”, emiten bloques que son aceptados por la red. Esto ya que no se cumplieron con todos los parámetros del BIP 34, por lo que los bloques de la versión 1 seguían siendo válidos. Sin embargo, a partir de que se alcanzó el 95% (que representa un total de 950 bloques) de los últimos 1000 bloques generados, los nuevos bloques producidos por los mineros marcados con la versión “1” se consideran inválidos y son rechazados. Ya que a partir de aquí, los bloques únicos válidos eran los que estaban marcados con la versión “2” y que disponían de la altura de bloque en la entrada de la transacción coinbase.
Esta transición en dos partes permitió a los mineros tener tiempo de actualización de sus sistemas para aceptar los cambios propuestos, de forma continua y sistematizada. Sin requerimiento que todos los mineros implementaran el cambio al instante y al mismo tiempo.
Otras implementaciones de MASF
Luego de la implementación exitosa del BIP 34, este mecanismo se logró de la misma forma para la activación de los BIP 66 (restricción de las firmas estrictas de DER) y BIP 65 (OP_CHECHECKLOCKTIMEVERIFY). Donde se implementó la misma estructura de señalización, sólo que para BIP 66, los mineros debían señalar su aceptación de la bifurcación cambiando la versión “2” por la versión “3” en los últimos 1000 bloques generados. Quedando inválidos todos los bloques de la versión “2” cuando el 95% de los bloques minados acepten la versión “3”.
Así mismo, para la activación de BIP 65, los mineros deberían hacer una transición desde la versión “3” a la versión “4”, de igual forma, en los últimos 1000 bloques generados en la red. Invalidando a los bloques de la versión “3” cuando el 95% de esos 1000 bloques minados se realizaron el cambio a la versión “4”.
Pero este mecanismo para incrementar las versiones de 1 en 1 con cada activación se hizo limitado. Principalmente porque sólo era posible aumentar las versiones 1 a la vez, y porque también se limitaba a tener que estar activada la bifurcación suave anterior para poder activar la siguiente.
Por lo que posteriormente, se implementaron nuevos cambios propuestos en el BIP 9, donde cambió el mecanismo de señalización por parte de los mineros. En este punto el número de versión del bloque no marcaba la señalización. En su lugar, se basaría en la interpretación del campo de versión como un vector de bits. Es decir, que la activación de la bifurcación suave se realizaría por medio de diferentes bits en el campo de versión. De esta forma se dejaba atrás el procedimiento de incrementar el número de versión.
Esto permitió una gran ventaja frente a la versión anterior, puesto que permitió agregar y activar un número mayor de soft fork de forma simultánea, en lugar de una única vez.
Implicaciones de la implementación de MASF
Las bifurcaciones suaves activadas por los mineros (MASF) permiten que las nuevas reglas de consenso sean activadas en el protocolo una vez que la mayoría de los nodos se actualiza y las acepta.
No obstante, como para realizar este proceso los mineros utilizan sólo su poder de hash esto puede ser inconveniente. Esto porque implica que la potencia de cómputo o hash rate indica que la bifurcación está acabada. Sin embargo, en realidad están operando en las versiones anteriores sin el soft fork. Algo como esto ocurrió con el BIP 66. En ese momento, muchos mineros señalaron las reglas pero no las aplicaron. Esto llevó a los mineros a crear una nueva cadena (hard fork). Aunque esta es rechazada por los mineros que sí aplicaron el BIP 66. Lo que significó que esos mineros perdieran todas las recompensas y el poder computacional invertido.
