Upcoming changes to Cardano - Vasil hard fork
The Cardano network will soon be transitioning from Goguen to Basho via two planned hard forks (for more information on Cardano Era please visit this page) The Basho era is about optimizing and scaling the network to better support Defi applications and facilitate growth and adoption. The first hard fork is called the Vasil hard fork and will see the release of new integration components impacting all projects.
Vasil hard fork
The Vasil hard fork is planned to be delivered. This will require an upgrade of all core components for example cardano-node, cardano-wallet etc.
The core components for the Vasil hard fork are expected to be made available around the end of May. Once officially released we will notify you of the appropriate time to upgrade.
The Vasil hard fork will introduce the following key network improvements:
Plutus version 2.0
Plutus 2.0 is being released and includes improvements in four key areas :
1) Reference scripts CIP-33 - This improvement introduces the ability to have on-chain pre-recorded scripts that can be referenced by other transactions. This will make the transaction size smaller and easily referenced by other transactions.
2) Reference Inputs CIP-31 - With this improvement you can reference input from a script without consuming it, this will allow many scripts to reference the same input thus improving concurrency.
3) Inline datums CIP-32 - This improvement will simplify the process of referencing inputs by removing the need to use hashes.
4) Redeemers in transaction information - This will let scripts co-operate by using shared redeemers.
Crypto primitives are used in Cardano as building blocks for other more advanced functionality. This release introduces some changes around the VRF (Verifiable Random Function) and its schedule in determining who will mint the next block. In the upcoming release, Cardano will only need to use it once thus improving performance and syncing time without losing security
Executing a Plutus Smart contract initiates a two-step validation process. In the first step, the script is executed offline, and if successful it moves to the second step, execution on-chain. Scripts are not allowed to execute on-chain without collateral and so users must include a fee to cover the cost of executing the script. If script execution fails then the collateral is lost. This new improvement implements a safety net where a failing script will only lose the min amount of collateral and not the total amount put forward.