Vasil

El Vasil Hardfork (originalmente llamado Babbage) es la sexta bifurfación de la historia de Cardano. Su fecha de implementación fue el 22 de Septiembre de 2022, para el cual el protocolo pasa de la versión v6.0 a la v7.0 .

Esta bifurcación se caracteriza por incorporar un nuevo lenguaje de programación para implementar contratos inteligentes llamado Plutus v2; y por incorporar features orientadas a mejorar la escalabilidad de la red.

Origen del nombre

El nombre tiene su origen en Vasil St Dabov, un reconocido miembro de la comunidad (Embajador Global de Cardano) fallecido en el año 2021. Entre sus hazañas por las que es recordado destaca el haber plantado más de 10 mil árboles a lo largo de su vida.

En referencia a Babbage, el nombre tiene su origen en Charles Babbage.

Para ponerlo en una analogía, si Ada Lovelace es la madre de la computación, Charles Babbage es el padre.

¿Qué implementaciones trae?

Lenguaje de programación Plutus v2

Se implementa una nueva versión del lenguaje de programación de smart contracts de Cardano, llamada Plutus v2. El mismo extiende las funcionalidades de Plutus v1

Se diseñó de manera tal que se mantenga la retrocompatibilidad. Es decir, aquellos contratos inteligentes implementados (o que se implementen a futuro) con versiones anteriores del lenguaje (Native Scripts o Plutus v1) seguirán funcionando con normalidad.

CIP (Cardano Improvement Proposals)

Estas implementaciones han surgido en propuestas sugeridas y debatidas por la comunidad, a través de los Cardano Improvement Proposals:

CIP 31 - Reference Inputs/Entries: Entradas referenciadas, permite leer una transacción input sin tener que consumirla, lo que permite no tener que generar otra transacción con el mismo valor en su reemplazo para una lectura posterior.

CIP 32 - Inline Plutus Datums: Permite insertar datos crudos dentro de un Plutus script sin tener que utilizar obligatoriamente hashes para representarlo.

CIP 33 - References Scripts Sharing: Permite utilizar las referencias a un script para reutilizarlo sin tener que escribirlo nuevamente en cada transacción. Con ello se reduce considerablemente el tamaño de las transacciones que contengan Plutus scripts. Como va a reducir el tamaño de la transacción, también va a bajar el fee de dichas transacciones. Combinando CIP 33 y Script Compresion, las transacciones de script Plutus se podrían reducir para que ocupen un promedio de 2KB.

CIP 40 - Collateral Outputs: Elimina la necesidad de establecer previamente una cantidad de garantía (collateral) en las Wallets para poder interactuar con smart contracts. Esta garantía se asignará de forma transparente para el usuario, sin requerir de su intervención. Esto se logra gracias a la incorporación de un nuevo campo en la salida de las transacciones llamado Collateral Output.

Se elimina el parámetro 'd' (descentralización) del protocolo

El parámetro 'd' define que porcentaje de la producción de bloques será realizada por nodos federados (centralización) y que porcentaje por nodos no federados (descentralización).

Si d=1 significa que el 100% de los nodos (stakepools) que producen bloques son federados (centralizado)
Si d=0 significa que el 100% de los nodos (stakepools) que producen bloques son de la comunidad (descentralizado)

Al inicio de la Era Shelley (la era de la descentralización) el parámetro d era igual a 1, es decir que todos los nodos productores de bloques pertenecían a IOG. Luego el valor de este parámetro se fue decrementando gradualmente hasta llegar a 0. Permitiendo la comunidad controlar completamente la producción de bloques.

El riesgo radica en el hipotético caso en que el valor de este parámetro sea nuevamente establecido en 1. Se centralizaría instantáneamente la producción de bloques, atentando gravemente contra la descentralización de la cadena.

Vasil Hardfork mitiga este riesgo eliminando al parámetro d de forma irreversible, asegurando así que la producción de bloques se mantenga descentralizada por los SPO (stakepool operators) de la comunidad.

Diffusion Pipelining

La difusión por tuberías lo que permite es obtener una propagación de bloques más rápida. La idea es reducir los "tiempos muertos" entre bloques.

Propagación Serializada (Sin Pipelining)

Actualmente este proceso de propagación de un bloque por la red se encuentra muy serializado.

Los 6 pasos por lo que atraviesa el bloque son:

Transmisión del encabezado del bloque
Validación del encabezado del bloque
Solicitud y transmisión del cuerpo del bloque
Validación del cuerpo del bloque y extensión de la cadena local
Transmisión del encabezado del bloque a nodos descendentes
Bloquear la transmisión del cuerpo a los nodos aguas abajo

Propagación Paralelizada (Con Pipelining)

La implementación de difusión por tuberías permite agilizar el circuito de propagación al paralelizar los pasos de la propagación.

Concretamente la mejora consiste en mejorar la propagación al darle a los nodos la habilidad de pre-notificar a sus nodos pares del próximo bloque sin que haya sido validado, habilitando a éstos a ir pre-cargando el cuerpo del mismo.