The Vasil Hard Fork — From a dApp Builder’s Perspective

Introduction

Cardano, like any other blockchain, is constantly evolving, and on-chain evolution often happens with a hard fork to enact new or updated functionality.

On Cardano, these events come a few times a year, and are often named after important figures. The next one of these, named the “Vasil hard fork,” is almost here and is hotly anticipated by many. This significant step introduces a range of new features that will enhance Cardano’s performance, throughput and scalability. In turn, exchanges and DApps interacting with — or built on top of — the blockchain will also be affected, as some of the changes will not be backward-compatible.

This post is structured in four parts: background information about hard forks (and the hard fork combinator, the unique technology that Cardano uses during hard fork events), what’s included in the Vasil update, what developers and other chains should expect, and the options open to the SundaeSwap community following the implementation of Vasil.

Hard Forks

There are many definitions floating out there, but the simplest is: a hard fork is a radical change to a blockchain’s protocol that often (but not always) results in the creation of two branches (‘forks’), essentially two blockchains. During a hard fork event, some transactions that would have been valid before the fork may become invalid on the upgraded fork. Because of this, a hard fork requires that all network nodes upgrade to the new protocol rules. These changes may be radical, but hard forks are relatively common.

A blockchain can undergo multiple hard forks. For example, Bitcoin has had four major hard fork events: Segregated Witness (SegWit), Bitcoin Classic, Bitcoin Cash, and Bitcoin Gold (2015 for SegWit, 2016 for Classic, and 2017 for Cash and Gold), plus a myriad of other smaller forks.

Ethereum meanwhile has also undergone multiple hard forks. Notably, one of Ethereum’s major forking events was sparked by the now infamous 2016 DAO hack, resulting in a network split. The fork was done, somewhat controversially, to return the stolen ether (all $60 million of it) to its owners. This was done by rolling back the Ethereum chain, which effectively created a new fork: Ethereum Classic. Those who refused to accept the hard fork (and the return of the funds to their owners) stuck to Classic. Everyone else moved on to the Ethereum chain that remains one of the major crypto players to this day.

Cardano’s Hard Fork Combinator

Hard fork events are often deemed ‘traumatic,’ in the sense that they cause significant disruption to chain activity. Sometimes, the network must be stopped for a time altogether to implement the new code base. Nodes that are not upgraded quickly enough will reject the new rules; DApps might experience unexpected behavior or stop working altogether; and so on. Regardless of what triggered the fork, whether it was planned (as Vasil is), or whether it occurred in response to adversarial behavior (such as the DAO hack), a hard fork is no small task. They require very careful planning, testing and implementation.

One core principle held by Cardano’s developers is in the importance of ‘smooth’ code updates. So they came up with an ingenious way of ‘softening’ the impact of hard forks on their chain and eliminating the ‘trauma’ associated with these on-chain events: the hard fork combinator (HFC). This piece of technology does exactly what it says on the tin: it combines two protocols into one single protocol. Cardano engineers refer to this as “sequential combination.” In practice, following the forking event, the chain runs the original protocol for a time before switching over to the updated protocol.

Herein lies the uniqueness of the HFC. Since block production does not stop, there is no break on the chain, leading to a smooth and graceful transition between protocols. As an analogy, think of the evolution of the Cardano blockchain as a relay race, with every hard fork representing the point when one runner hands the baton over to the next one. And for a few moments, both run in perfect synchrony, to ensure the baton handover goes smoothly. Then, the relay runner takes off. On Cardano, these events happen a few times a year, and so are often given specific names. The next one, happening soon, is the “Vasil” hard fork.

What the Vasil Update Brings

Vasil has been running on a testnet since 20:20 UTC on July 4. The testnet deployment enables two things: the monitoring of on-chain code behavior, and preparation for the final integration process. It gives project developers, stake pool operators (SPOs), and exchanges time to test their code on the new fork ahead of the planned mainnet deployment on July 29th.

Vasil represents a very significant update for Cardano. According to the official blog post, this update will bring increased functionality, performance, scalability and interoperability to Cardano through several mechanisms, including diffusion pipelining and four Cardano Improvement Proposals (CIPs), CIP-31, CIP-32, CIP-33 and CIP-40. We’ll explain each of these below.

Diffusion pipelining improves block propagation times, thus enabling higher throughput. Essentially, pipelining streamlines the way in which blocks are validated and propagated — the goal being the propagation of a block across the network well within five seconds of its creation. Pipelining achieves this by allowing a block to be propagated before full validation has occurred.

Reference inputs (CIP-31) — A datum is simply a piece of information. In the extended unspent transaction output (eEUTXO) model that Cardano uses, each output of a transaction carries (the hash of) some datum. Pre-Vasil, this meant that for a script to “see” a datum, it had to be spent as one of the inputs to the transaction. This in turn only allowed one transaction to use that datum at a time. The entire process was very inefficient.

The reference inputs feature enables looking at the information contained within an unspent output without having to actually spend it. This allows many transactions to read and utilize this data in parallel.

This also simplifies some transactions, as the dApp doesn’t have to worry about “recreating” the datum correctly in each transaction.

Inline datums (CIP-32) — The inline datum feature allows the contents of a datum to be stored directly on the output, rather than just the hash. This greatly simplifies the job of off-chain code, since it no longer needs to independently store the datum that correctly hashes to the output it needs to spend.

Reference scripts (CIP-33) — The size of a script presents certain problems. Passing a whole script inside each transaction consumes a huge portion of an already tight budget that a dApp developer must adhere to, inflates the chain with redundant data, painfully limits overall chain throughput, and incurs higher (and equally unnecessary) transaction fees. The size of a transaction can be limited to protect the chain, but this limits what dApp developers can achieve, and impacts the Cardano end user experience.

Reference scripts resolve these issues by attaching a script directly to an output (much like a datum), and referencing that script from a separate transaction. This enables transactions to look up (or ‘reference’) those scripts during validation, as opposed to having the transaction pass entire scripts time and time again.

Reference scripts allow the ability to fit more of a previously printed script into a future block.

The inclusion of reference scripts means that transactions using reference scripts carry less data, which makes these transactions smaller. This, in turn, means that dApp developers can implement more features, transactions are quicker to process, and thus cheaper. This significantly reduces transaction fees for the user.

Reference scripts will allow dDApps to pay the on-chain storage cost once and reuse it.

Collateral outputs (CIP-40) — Submitting a Plutus transaction requires collateral (set at 150% of the transaction fee), to avoid possible Distributed Denial-of-Service (DDoS) attacks. Pre-Vasil, if a malicious or buggy dApp or wallet were to submit a transaction that failed phase-2 validation (for more on phase-1 vs phase-2 validation, see this great article), a user would lose all funds stored in the collateral UTXO. Those funds would go towards the ‘fee pot’, compensating the SPO and delegators that wasted resources checking an invalid transaction.

Post-Vasil, developers will be able to specify an address to receive the collateral change, so even if the transaction fails validation, only the collateral amount will be taken, and the remaining funds are sent to the specified change address.

In this image, different colored coins represent native tokens.

Verifiable Random Function (VRF) process enhancement — Pre-Vasil, block validation required two VRF functions per network hop. Following the update, block validation will require only one VRF function, which will result in faster validation.

Plutus V2: Updates for Plutus V1 Introduced In Vasil

The Vasil update includes three specific enhancements to Plutus v1 scripts, which, for the sake of brevity, we’ll only briefly list here:

• Plutus evaluator speed improvements
• Updated cost model parameters
• Datums and redeemers of other inputs

What to Expect Following the Vasil Update

Vasil — named in honor of the late Vasil St. Dabov, a Cardano ambassador who passed away in 2021 — is a big deal for Cardano, due to the sheer scope and impact of the new features and upgrades being introduced. In the words of IOG, Vasil is the most significant network upgrade since the deployment of staking via Shelley.

Following the update, Cardano will become more scalable and flexible for developers to create newer and better DApps to suit more use cases.

One common question is how the hard fork and the new features it brings will impact already deployed dApps. The simple answer is that it won’t: the Cardano blockchain remains backwards compatible, and can still execute these transactions as before.

The more nuanced answer is, of course, also the more interesting. First, while existing contracts will continue to work, they will be unable to make use of the new features: any transaction using a reference script or an inline datum, for example, must only include funds locked by a Plutus V2 script. This means that there’s no risk that these new features change the security guarantees of the old contracts, but also means that dApp developers will have to change their contracts to benefit. We anticipate this will likely require a new audit, for example.

Additionally, while on-chain code is unaffected, many dApps work hand-in-hand with “off-chain” systems. These systems do things like construct transactions, or roll-up statistics about the global state of the dApp. The off-chain code of a dApp needs to be updated to recognize and correctly interpret the new post-hard-fork transaction formats. Depending on the dApp, this can be simple, or very complex, and often there are multiple organizations who have to coordinate. At SundaeSwap, we’ve been hard at work on this, and thought it might be interesting to outline some of this work and give a glimpse into what each dApp developer and ecosystem builder has likely been up to.

How Vasil Affects SundaeSwap

As mentioned above, on-chain contracts (the most security-sensitive area of the dApp) are unaffected. Here is a sampling of some of the off-chain systems that have needed updating. We’ve had to:

• Update “Ogmigo”, our Go client library for reading from Ogmios to recognize the newly added fields
• Update our transaction construction to create valid post-Vasil transactions, without impacting the script compilation and changing the script hashes
• Update the scooper software to work around a performance degradation in the cardano-node around querying UTXOs
• Update many places where we look up the value of the input to a transaction, which now may point to a collateral output
• Conduct a general review of all code related to statistics roll-up and yield farming, to identify places where our assumptions may now be violated
• Thoroughly test all of these changes

Additionally, while the currently deployed contracts can’t take advantage of the savings and scalability improvements, we were already working on a new version of the contracts. It’s still early stage, but this work includes some dramatic improvements and new ideas we’ve identified since our launch, and is designed to take full advantage of the Vasil features once they are finished, fully audited and released. We’ll have more details on that when we’re further along in the development lifecycle.

The Vasil hard fork will bring a diverse set of improvements to our nascent ecosystem. This will be the first Cardano hard fork performed in collaboration with a diverse set of DeFi partners, and is therefore a key milestone in demonstrating Cardano’s unique ability to evolve and innovate. We’re ecstatic to be a part of it, and proud to be a part of the careful, methodical approach that reflects our shared Cardano ethos.