Forks

De ALDEA WIKI
Ir a la navegación Ir a la búsqueda
Representación gráfica de bifurcaciones

Un fork o bifurcación en el contexto de la tecnología blockchain (cadena de bloques), es un cambio drástico en el protocolo de la red, lo que genera la división de la misma en dos cadenas cada una con sus propias reglas independiente de la otra.

Tipos de bifurcación

Los términos soft fork y hard fork describen cambios de compatibilidad en el protocolo subyacente.

Hard Fork

Un hard fork ó "bifurcación dura" en Español, es aquel evento en el cual una blockchain sufre cambios fundamentales en su estructura y protocolo. Estos cambios radicales generan que la red se divida en dos cadenas independientes.

En la mayoría de las blockchains, un hard fork indica cambios en los bloques o un cambio en su interpretación. Tradicionalmente, al realizar un hard fork, el protocolo original deja de funcionar, se implementan nuevas reglas y la cadena de bloques es reiniciada. Es importante entender que una cadena de bloques que ha sufrido un hard fork es diferente a la versión previa de la misma.

Esto implica que los nodos anteriores negarán los bloques recientemente actualizados, y la nueva blockchain funcionará bajo nuevas reglas que negarán continuamente los bloques de la antigua blockchain de forma indefinida. Este tipo de actualización de software no es compatible con versiones anteriores.[1]

Soft Fork

Una "bifurcación suave" es una modificación de las normas que es compatible con el futuro. La antigua blockchain seguirá aceptando bloques de la nueva plataforma avanzada de blockchain, ya que la bifurcación es una alteración compatible con el futuro, aunque las normas se hayan modificado debido a la nueva actualización.

A grandes rasgos, un soft fork convence a la antigua red de blockchain para que acepte las reglas alteradas, permitiendo así que tanto los bloques de transacciones actualizados como los antiguos sean aceptados al mismo tiempo.

Un soft fork, a diferencia de un hard fork, mantiene viva la antigua blockchain conservando dos carriles con regulaciones y normas separadas. La actualización del protocolo Bitcoin Segregated Witness (SegWit) en Agosto del 2017, es un ejemplo de la implementación exitosa de un soft fork.

Razones y causas

Cualquier programa o software, como toda blockchain, requiere de actualizaciones para seguir creciendo y mejorando. Los forks nos permiten realizar cambios de forma descentralizada en la blockchain sin la interferencia de una autoridad central. Sin ellos, las blockchains no podrían adoptar nuevas funcionalidades, lo que llevaría al estancamiento y la disminución de su caso de uso.

Bifurcaciones en Cardano

Hard Fork Combinator Event

En Cardano, el Hard Fork Combinator Event (HFC) o "Evento Combinatorio de Bifurcaciones Duras" en Español, es un proceso diseñado e implementado por IOHK que permite realizar mejoras y actualizaciones de la red de Cardano sin interrupción o reinicio (no-disruptivo).[2]

Este tipo de actualización de software se caracteriza por mantener la retrocompatibilidad con versiones anteriores.

Esta decisión temprana en el diseño de la arquitectura ha permitido implementar mejoras sustanciales, como la incorporación de stake pools en el hard fork de Shelley o la implementación de contratos inteligentes con Alonzo, sin necesidad de reiniciar la blockchain y permitiendo que los SPO realicen una transición gradual en el proceso de actualización de sus nodos a la nueva versión.

Se puede decir que la cadena actual se encuentra conformada por los bloques de todas las sub-cadenas combinadas previamente (exceptuando la primer sub-cadena previa a la bifurcación OBFT dado que fue un hard fork tradicional disruptivo).

Este combinador facilita la transición y evolución de Cardano a medida que nuevas funcionalidades son incorporadas y la hoja de ruta del proyecto es implementada.

Bifurcaciones en la red de Cardano

Historial

  1. Ouroboros Byzantine Fault Tolerance - 20 de Febrero del 2020 (Epoch 176). La primer bifurcación dura de Cardano se caracteriza por haber sido un hard fork tradicional (disruptivo). En esta bifurcación se sientan las bases para que las bifurcaciones duras posteriores puedan realizarse utilizando el Hard Fork Combinator (no disruptivo).
  2. Shelley - 29 de Julio del 2020 (Epoch 208). Este fue el primer hard fork utilizando el hard fork combinator. La segunda bifurcación dura de Cardano se caracteriza por implementar el Proof of Stake, donde inicialmente el 100% de la producción de bloques era realizada por nodos federados (centralizado). Luego, con el correr de la Era Shelley, se fue decrementando gradualmente el parámetro d (decentralizacion), para que la producción de bloques pasara a estar controlada por los SPO de la comunidad (descentralizado).[3] El protocolo pasa de la versión v1.0 a la v2.0 .
  3. Allegra - 16 de Diciembre del 2020 (Epoch 236). La tercera bifurcación dura de Cardano se caracteriza por implementar el Token Locking. El protocolo pasa de la versión v2.0 a la v3.0 .
  4. Mary - 1 de Marzo del 2021 (Epoch 251). La cuarta bifurcación dura de Cardano introduce tokens nativos (FT (Fungible Token) y NFT (Non-Fungible Token)) y el multi-asset support. Lo que permitió la creación y transacción de tokens y NFTs creados por la propia comunidad. [4] El protocolo pasa de la versión v3.0 a la v4.0 .
  5. Alonzo - 12 de Septiembre del 2021 (Epoch 290). La quinta bifurcación dura de Cardano introduce los esperados contratos inteligentes, lo cuales se pueden programar con la primer versión del lenguaje Plutus v1. De esta forma la red de Cardano se convirtió en una blockchain tercera generación propiamente dicha.[5] El protocolo pasa de la versión v4.0 a la v5.0 .
  6. Vasil - 22 de Septiembre del 2022 (Epoch 365). La sexta bifurcación dura de Cardano se caracteriza por incorporar varias mejoras de escalabilidad (CIP 31,32,33,40 y Difussion Pipelining), extender las funcionalidades del lenguaje de programación (implementando Plutus v2) y fortaleciendo la descentralización de la red (al eliminar de forma irreversible el parámetro d). El protocolo pasa de la versión v6.0 a la v7.0 .

Referencias


v1.0 - Escrito por Martin-ITZA, revisado por MRTN - 09-09-22

v2.0 - Actualizado por Jotape, revisado por Martin-ITZA - 21-09-22