The Alonzo upgrade enables the creation of smart contracts, decentralized applications (DApps), and other applications on top of Cardano.

Alonzo marks a significant milestone in the Cardano journey, deploying base level scripting capability that will, in turn, enable further innovation and network development. It also starts the process of transforming a transactions & tokens based blockchain into a dynamic confluence of creativity, financial inclusion, and decentralized development.

Among the most exciting of the fresh developments enabled by Alonzo is Hydra, a key layer 2 solution to further improve Cardano's scalability layering a new protocol on top of the existing layer 1 blockchain.

Hydra: Cardano’s layer 2 solution

In a blockchain network, a consensus algorithm creates a secure and trustless environment by ensuring agreement on a transaction history. Cardano uses Ouroboros, an efficient proof-of-stake consensus algorithm, for this very purpose. But Cardano also, just like any permissionless blockchain, faces challenges when trying to scale to achieve the throughput required to support applications in the real world, including payment, identification, game, or mobile services. After all, the blockchain needs to reach global consensus on each and every transaction.

Cardano transactions incur fees. The people who run the network (in the case of Cardano, the stake pool operator community) need to be rewarded appropriately for the part they play, so fees need to be set at a sustainable level. Users want to pay fees they deem acceptable. In addition, the blockchain needs to be protected against Denial-of-Service (DoS) attacks, for example. Fees can therefore not be set so low as to open up undue risk – DoS events must be made prohibitively costly to a potential attacker. Storage is also a concern, as an ever-growing transaction history can lead to storage problems. Effectively, the most successful blockchains risk becoming ‘victims’ of that very success.

Hydra is a layer 2 scalability solution that seeks to address all these concerns and aims to maximize throughput, minimize latency, incurring low to no costs, and greatly reducing storage requirements.

Scaling isomorphically

So how does it do this? By providing more efficient means of processing transactions off-chain for a set of users, while using the main-chain ledger as the secure settlement layer, Hydra keeps security guarantees while remaining loosely coupled to the main chain. Not requiring global consensus, it can adapt to a broad range of applications. For example, Hydra allows Tx fees and minimum UTXO Value to be configured as low as 1 or 2 lovelaces, critical to microtransactions and the use cases these unlock.

Most importantly though, Hydra introduces the concept of isomorphic state channels: that is, to reuse the same ledger representation to yield uniform, off-chain ledger siblings, which we call Heads (hence the Hydra name, which references the mythological, multi-headed creature). Specifically for Cardano, this means that native assets, non-fungible tokens (NFTs), and Plutus scripting are available inside each Hydra Head. Isomorphism permits a natural extension of the system, rather than a bolted-on one.

Many of the transactions currently handled by the main-chain or application running on the main chain can benefit directly from Hydra, because it understands just the same transaction formats and signatures. This greatly lowers the entry barrier to Hydra for existing and potential new customers, who can reuse Cardano's tried-and-tested infrastructure for building wallets and applications interacting with the layer 2 system. Also, a Hydra Head can be created without initial funds on a receiving party’s side, which allows for a smooth user experience.

Developing a proof of concept

We have already implemented the basic Hydra Head protocol as a proof of concept hydra-node. A developer preview will be ready by the time of the upcoming Cardano Summit. This will enable developers (or anyone interested) to run one or more hydra-nodes online, opening a Hydra Head with a limited number of participants, and feeding transactions to it. Users can expect to see a working prototype over a dedicated testnet, plus early benchmarking figures and documentation in this GitHub repository. There likely will not be any user-facing components (wallets, user interface, etc.) available just yet.

It is also important to make a point about transactions per second (TPS), too often rather clumsily used as the sole measure of ‘success’ when it comes to scalability. Some people tend to rate a network on the basis of its maximum throughput measured in throughput (TPS). While this is a reasonable measure for ‘legacy’ systems where there is high predictability and conformity (e.g., the VISA network) it is a less useful metric for distributed systems. Instead, our initial focus is on latency (the time that elapses until a transaction is confirmed) as another, more practical way to measure speed of blockchain transactions. On the mainnet, minimum latency is 20 seconds (one block). This is the starting point. In a layer 2 system like Hydra, it is possible to achieve confirmation times of less than one second. Terms like ‘one million TPS’ have been used before. It is a bold number, and while this remains as an aspirational target, the ultimate goal of any system is the flexibility to grow capability with demand. Throughput measured in TPS per Hydra head is secondary, and mostly limited by the available hardware. In principle, by adding increasing numbers of Hydra heads to the system, arbitrarily high throughput can be achieved by the system as a whole.

Hydra's evolution over time

In the short term, we will keep developing the hydra-node and the Hydra Head protocol until it becomes a solid and stable foundation for the community (and us!) to build real-world applications. These new apps will benefit from fast settling and low-to-no-cost transactions. We are also actively developing other key features, including the support of multiple heads per node, persistence, and Head protocol extensions

In the medium term, say 6-12 months, progress will greatly depend on the results of our research and experimentation, plus feedback from the developer community. We are researching ways to interconnect multiple Hydra Heads to increase the “reach” of our layer 2 solution, for example, and also testing different methods to make it easier to integrate and use Hydra. One of the most exciting visions for the long term is the development of ‘Virtual Heads’ by running the Hydra Head protocol inside Hydra Heads, thus fully utilizing the isomorphism of our Layer 2 solution. Herein lies true, theoretical limitless scalability.

Flexibility is key to scalability & growth

The overarching concept for Hydra is the provision of a pioneering layer 2 scalability solution suitable for Cardano, a third-generation, UTXO-based blockchain capable of supporting smart contracts. Hydra will drive down costs while increasing throughput and maintaining security.

Hydra replicates the main chain's functionality while minimizing friction for users, but still allows the flexibility of having a different fee / cost structure and timing constraints on the layer 2. Any successful ecosystem balances the needs of all users. We want this ecosystem to serve the needs of individual consumers, enterprises, professionals, and the growing list of DApps and their developers.

With the Alonzo hard fork, Cardano will start on a new journey as a smart contract platform, enabling technologies like Hydra, which in turn will dramatically improve Cardano’s scalability, and thus further its adoption.

At the Cardano Summit 2021, taking place 25-26 September, we’ll talk more about Hydra, its progress to date, and goals for the future. Make sure you join us! And you might also like to check out this video explainer.

Matthias Benkort, Arnaud Bailly, and Fernando Sanchez also contributed to this piece.

Later today, we'll deploy Plutus smart contract capabilities onto the Cardano mainnet via a hard fork combinator (HFC) protocol upgrade event.

The Alonzo upgrade will bring highly anticipated capabilities to Cardano through the integration of Plutus scripts onto the blockchain. These will allow the implementation of smart contracts on Cardano, enabling a host of new use cases for decentralized applications (DApps) for the very first time.

It’s only just the beginning. But this is still a moment for celebration. As a community, we have been on an incredible journey together. Rightly, we should allow ourselves to acknowledge the tremendous efforts made by so many to get here. This will also be a time for reflection on the challenges we've collectively overcome.

While we might allow ourselves some brief downtime, this is no moment to rest up. And there is certainly no room for hubris. This is where the mission truly begins as we – the whole community – start delivering on the vision we have all been working towards for so long. Building a decentralized system that extends economic identity and opportunity to everyone, everywhere.

The road to here

While many years of research and development have prepared the ground, it was the Byron reboot in March 2020 that truly laid the foundations for the network we have today, by providing a robust and scalable code base on which to build. In July the same year, the Shelley upgrade shifted Cardano from a federated model towards a decentralized one.

Since the end of March 2021, when we adjusted the network decentralization parameter to D=0, every block has been produced by a decentralized network from a community of 2,868 stake pools.

It’s a remarkable staking ecosystem that continues to grow rapidly. According to statistics from Cardano data aggregation tool Pooltool, the number of ada staking wallets today stands at 825,755. This represents an increase of 35%+ since June. At the time of writing, the total ada delegated to stake pools is valued at $ 59.86 billion, accounting for 71.4% percent of total ada supply ($ 83.9b).

March’s Mary upgrade created a multi-asset network and introduced native tokens. As well as providing an alternative to the ERC20-type model, Mary released a Cambrian Explosion of creativity. With low minting and transaction fees and, uniquely, no need for smart contracts for Cardano NFTs, we have seen the blooming of an incredible NFT ecosystem. According to data from pool.pm (powered by Smaug pool), Cardano has seen 780,436 tokens minted to date and 19,419 policies. All without the need for smart contracts.

Enter Alonzo

The Alonzo upgrade (named after the pioneering American mathematician Alonzo Church), will build on this success. Deployed using the same HFC technology used in previous upgrades, this will mark the beginning of a fresh period of rapid growth. By allowing Plutus scripts to be written and executed on-chain, we’ll have the backbone for a new decentralized application platform, enabling numerous DApp and decentralized finance (DeFi) use cases – from simple swap type apps to decentralized exchanges (DEXs), and more complex computational programs such as Oracles and crypto-backed algorithmic stablecoins.

So, we have one of the most decentralized, sustainable, robust, and advanced blockchain platforms in the world, run by a skilled community of stake pool operators (SPOs). We enjoy an informed and passionate community of delegators. We have a thriving NFT ecosystem, attracted by the ease and low-cost of minting. Oh, and a roadmap for future governance through Voltaire and ultimate scalability through Basho and Hydra scaling. The future is bright and stretches far; we’ll continue to travel the long road together.

The birth of a new developer ecosystem

All the core building blocks are in place. Platform. Vision. Mission. Community. It is still very early days for smart contracts and DeFi, yet we have made great progress already.

Thousands of developers have been taking part in the Plutus Pioneers course, learning the fundamentals of Cardano’s native development framework. Scores of projects have already started developing in Plutus and are at various stages of expertise and readiness. Hundreds of projects have been actively working on the various Cardano testnets and privately-hosted solutions. Some 150 projects are developing their ideas via Cardano’s Project Catalyst innovation program, the world’s largest decentralized innovation fund. In the latest round, 800 – yes, 800 – projects applied for $4m-worth of funding. With a treasury now worth well north of $1bn at today’s values, and 33k+ members, the future for building on Cardano couldn’t be brighter.

For a snapshot of just how many projects and organizations comprise the ecosystem, visit our Essential Cardano repo. Or check out the various excellent ecosystem maps (these are representative, though none are comprehensive) out there like those from the Cardians (see Figure 1). These don’t represent what projects will be visible right away. But they offer a beautiful vista.

Figure 1. Ecosystem map by @Cardians_

We look forward to seeing these projects evolve as they head towards deployment. Some are close to the launch pad, others further off. Following the release of our first full public testnet earlier this month, and now the mainnet, we expect to see many start to ramp up their development activity.

We are still early

Let us be clear. There will be bumps in the road. Early user experiences might not be perfect. Some early DApps will have issues. We'll see some great development teams and some poor ones. This is a permissionless, decentralized blockchain, so this is inevitable. And a few DApps may prove insecure. Cardano’s secure layer 1 platform offers robustness and high assurance – and Plutus is designed to minimize the potential for exploits. But poor coding practice can always introduce risks for DApp users. Inevitably too, we can expect bad actors looking to take advantage via hacks, exploits, and the likes.

As a community, we need to be vigilant as our ecosystem matures. In fact, we believe that to mature across the industry as a whole, certification needs to be taken more seriously. At the summit, we’ll announce plans on how – along with a number of strategic partners – we’ll be supporting the creation of new standards and solutions.

Do Your Own Research

As ever, we encourage everyone to do your own research (DYOR). Look to your fellow community members for ‘crowdsourced due diligence’ and provide your own contributions. Look for projects with a positive history of open and transparent communication, properly maintained social channels/websites, and technical track records. Be sensible out there, especially in these early days. Alongside confidence in DApp security and project intent, DApp discovery will also be key to the healthy growth of the Cardano ecosystem. So expect to hear more on that at the summit, too.

The summit will also be a time for celebration, although there will be those who will seek to sour this. While our community is always open to being challenged in good faith, we have grown too used to Twitter’s and Reddit’s fear, uncertainty, and doubt (FUD) – from the biased and the willfully ignorant. Every project receives its share of this toxicity, and a greater degree is inevitable around major releases.

This is a disappointing element of our immature industry. We need to do better if we want to accelerate wider adoption. The FUD has been particularly virulent this past week. For me, it's a daily part of the job. Fortunately, most of my colleagues focus on building and don't concern themselves too much with CryptoTwitter™.

We shall see plenty more FUD and nonsense over the weeks ahead. Things will likely get uglier before they get better. Whatever. This will only strengthen our resolve to prove the naysayers wrong. We also have a vibrant and passionate community that never fails to support the project and respond with facts and courtesy. That continues to make everyone working on Cardano exceptionally proud. Thank you.

We are still early

Let’s remain steadfast through the storm. And focus instead on a bright horizon. We expect to see the first simple smart contract scripts deployed on Cardano within hours of the HFC event. It will take a while longer for more sophisticated DApps to start rolling out via the public testnet. With hundreds of projects building behind the scenes, we expect to see projects deploy through September and October, and accelerate through Q4. Especially with launchpads, tools and frameworks, including the Plutus Application Backend (PAB), and community-created APIs becoming available.

There are high expectations resting on this upgrade. Some unreasonably so. Cardano watchers may be expecting a sophisticated ecosystem of consumer-ready DApps available immediately after the upgrade. Expectations need to be managed here. We should remember that another well-known blockchain project which launched in July 2015 had to wait over two years before its first DApp (something to do with cats?) gained real user traction.

Steady iteration and improvements

Over the coming months, we’ll continue our cadence of fortnightly releases of new code, regular maintenance upgrades, and major HFC events each quarter. We shall continue to tune and optimize the platform, adjust performance, and refine pricing parameters as we track and monitor usage patterns. Only real usage will reveal how we need to adjust our flexible and scalable platform over the months of growth ahead. We shall also be looking to the growing developer community and the Cardano Improvement Proposal (CIP) process to bring further capability based on key requirements and needs.

The Alonzo HFC event will deploy Plutus 1.0, the core platform which itself will continue to evolve and bring more functionality over the coming months. Plutus is our native language, but of course, it is only the beginning here too. New bridges, sidechains, and other layer 2 solutions will bring in fresh options and an ever wider developer base. Future upgrades stemming from the work being done on Hydra will add further capability. Research papers like stablecoins, Babel coins, and stable fees will also in time start moving toward the prototype phase, bringing further innovation to the longer-term roadmap.

So, while we remain focused on continuing to research and develop longer-term utility for the platform, the ecosystem will evolve fast over the coming months. It's going to be quite a ride, with a huge amount of activity within the community.

Exciting times ahead

The Alonzo upgrade is a transformational network upgrade that will catalyze a blossoming ecosystem of developers, creators, and innovators. Later this month, we’ll have the Cardano summit. This week, we finalized the sessions. With over 100 sessions and more than 40 hours of content spread over multiple tracks across two full days, this will be the most significant event in Cardano’s history. It will be a celebration across virtual worlds and real-life meetups, a showcase of where we are today, and a forum to talk about where we’re heading. A reflection of a budding ecosystem that, while young, has always shown great maturity of purpose. And a platform for exciting new announcements.

So as we pass the epoch boundary today, let's take that moment. We can allow ourselves a celebratory whisky or two (even if it's just a cheeky splash in our morning coffee for our friends in Asia and the Southern hemisphere).

Let’s be proud of what we have achieved. But this is where the real work begins.

Let’s go.

Cardano is a UTXO-based blockchain, which utilizes a different programming paradigm for decentralized applications (DApps) from other account-based blockchains like Ethereum. The specific flavor Cardano uses is the Extended Unspent Transaction Output (eUTXO) model introduced by the Alonzo upgrade. eUTXO offers greater security allowing for smart contract execution cost predictability (without unpleasant surprises) and, as a result, offers a different approach to parallelization.

eUTXO inherits the per-branches design of the UTXO (Bitcoin) model, where one branch is by definition a sequence of transactions that requires a sequence of validations. To split the logic across different branches and enforce more parallelism, it is essential to build DApps and other solutions using multiple UTXOs. This provides benefits in terms of scaling, just like developing Bitcoin services prerequisites splitting one wallet into sub wallets.

DApps built on Cardano are not limited to one transaction per block. In fact, the block budget (that is the maximum number of transactions it can hold) allows the execution of hundreds of simple transactions and several complex scripts. However, the eUTXO model allows spending a transaction output only once. Given that users can face contention issues trying to access the same UTXO, it is important to use many different UTXOs. Note that this is important unless such a design would benefit from a strict ordering of clients. Sets of UTXOs can be used to implement design patterns that include semaphores. In addition, different users can interact with one smart contract without any concurrency failure. That is because a smart contract can handle a number of different UTXOs that make up its current state and off-chain metadata that allows interpreting those UTXOs.

Doing things in parallel

Blockchains achieve immutability and transparency of transaction processing differently. Any blockchain system should have a set of properties to meet the ever-growing need for secure yet swift operation processing, namely:

• Throughput – the number of operations a system can perform within a certain time period. This relates, for example, to the number of transactions or smart contracts processed in one second.
• Performance – how fast the system works. Performance measures the time of transaction or smart contract execution.
• Scalability – the ability of the system to perform multiple operations without overloading the network or influencing performance properties.

By increasing parallelism, we can ultimately improve the throughput of the system while keeping the performance of individual operations the same, but this sort of scalability will always be limited by the degree of contention.

When it comes to scalability, we also distinguish such system properties as concurrency, parallelism, and contention. Concurrency is essential to allow multiple actors to progress on a certain task without interfering with each other. Parallelism allows such progress at the same time without any interference. Contention occurs when those multiple actors interfere with each other while working either concurrently or in parallel.

Understanding concurrency

Concurrency may or may not improve a system’s performance, throughput, or responsiveness. The amount of concurrency limits the maximum number of simultaneous operations that can be performed.

To obtain actual performance improvements in a UTXO-based blockchain, processors or other actors should be able to perform multiple actions simultaneously. The higher the level of concurrency, the higher the maximum possible parallelism. Such an approach then translates to performance improvements and throughput. It also provides significant advantages over account-based systems (like Ethereum).

Deploying DApps on UTXO ledgers is different

Cardano’s approach to DApp deployment is different and thus it requires a learning curve and a different approach. This is like working with different programming languages: there is one goal – to deploy a solution, but so many programming languages to use for this purpose.

Maximizing concurrency is a skill that needs to be learned: developers need to write code in a way that severely restricts the opportunities for contention (e.g., by avoiding shared states and accidental dependencies). The system must then translate this concurrency into parallelism. A number of developers have already identified ways to approach this, while others are still developing solutions. Simply transplanting lessons learned on one blockchain will not work; while the learning curve is a little steeper, the results make this worthwhile.

Either way, it is important to understand that to deploy a scalable DApp on Cardano, a developer can’t just use an adapted Ethereum contract. Cardano is based on the UTXO model; it is not account-based. And this means that a single on-chain state will not meet the concurrency property on Cardano. Instead, DApps should split up their on-chain state across many UTXOs. This will increase the concurrency in their application, thereby allowing higher throughput.

Our education team has previously shared a simple AMM-style DEX implementation in the Plutus Pioneer course. While this is useful for teaching purposes, this architecture would not directly support a commercial DEX where an order book approach and additional concurrency are required. A developer looking to deploy on the Cardano mainnet would need to improve the scalability of the architecture accordingly.

We proposed a solution within our recent Djed stablecoin paper. For the Djed implementation on Cardano, an order book modeling pattern is favored whereby an order maker is responsible for forwarding any minting or burning order to the stablecoin smart contract, with an additional incentive fee imposed on each would-be buyer or seller of stablecoins and reserve coins. Several security mechanisms – via the extensive use of non-fungible tokens (NFTs) – are also used to guarantee the uniqueness of transactions, the correctness of each submitted order, and to prevent front-running attacks. NFT tokens are also used to report successful or failed minting and burning orders. We’ll publish a fuller article on this shortly.

To learn more about scalability, you can read how to design a scalable Plutus application and find out how to organize DApps on Cardano using order book patterns. Developers have also presented concurrent and deterministic approaches to the eUTXO smart contract architecture that might be regarded as a generalization of the parallel state machine steps introduced in the Hydra paper to realize multi-step state machines. A number of other developers and community members have also published papers, videos, articles, and useful threads on Twitter outlining their approaches. It’s a brilliant lesson in how the community will continue to develop its own innovative solutions, as approaches become more standardized with platform maturity.

Moving forward

The Alonzo hard fork event will introduce the core building blocks of Plutus 1.0. This is the beginning of ecosystem growth. Although it is still early, the Alonzo testnet allows our developers to assess system properties and build scalable DApps in advance – preparing for their mainnet launch. Dozens of projects have already been working with local instances of Plutus environments. With the main public testnet soon supporting smart contracts, we expect a significant ramping up of activity over the next few weeks and in the months ahead. Later this month, the Cardano summit (25-26 September) will showcase many of these projects, plus provide important updates on the smart contracts roadmap and the ongoing evolution of the technology stack. Developer events, hackathons, and, of course, the results of Project Catalyst will continue to bring new tools and abstractions to this fast-growing developer ecosystem.

If you are a developer, make sure to join our Discord community and get involved with Project Catalyst if you are looking to fund your project.

I'd like to acknowledge Lars Brünjes, Jann Müller, and Manuel Chakravarty for their technical input and support during the blog post preparation.

In our previous blog post, we discussed the deterministic nature of transaction and script validation on the Alonzo ledger, which provides assurance that the outcome of on-chain transaction application and script validation can be accurately predicted locally, before the transaction is ever submitted.

Relying on the guarantees provided by the deterministic design of the Alonzo ledger, we have implemented a specific two-phase validation scheme. It is designed to minimize the resources the nodes use to validate network transactions while also eliminating unexpected costs for the user. In this blog post, we dive deeper into how the two-phase validation works.

In the Shelley, Allegra, and Mary eras, transaction validation was a one-step process. The effect of a valid transaction on the ledger was fully predictable before it was applied. If a transaction was valid, it got included into a block and added to the ledger. If not, a node would reject it after a failed validation attempt and the transaction would not be included in a block. However, nodes that validated incoming transactions used time and resources, regardless of whether or not the transaction ended up in a block.

Alonzo introduces Plutus scripts, which might require significantly more resources to validate them compared to simple scripts in previous eras. To address the issue of nodes expending resources on validating scripts of transactions that get rejected, Alonzo introduces a two-phase validation approach. This strategy maintains a predictable outcome of applying transactions to the ledger, and also ensures fair compensation to the nodes for their work and resource usage.

Two-phase transaction validation

Transaction validation on Cardano is divided into two phases. The main reason for introducing two-phase validation is to limit the amount of uncompensated validation work by nodes. Each phase serves a purpose in achieving this goal. Roughly speaking, the first phase checks whether the transaction is constructed correctly and can pay its processing fee. The second phase runs the scripts included in the transaction. If the transaction is phase-1 valid, phase-2 scripts run. If phase-1 fails, no scripts run, and the transaction is immediately discarded.

Thus, nodes are expected to add processable transactions to a block even if the transactions are not phase-2 valid. This means that either:

• a small amount of uncompensated work is done by a node to find out that a transaction is not processable, but no expensive phase-2 validation is done, or
• the transaction is processable. The node can then perform phase-2 validation of the scripts, tag the transaction accordingly as either phase-2 valid or phase-2 invalid, and add it to a block. In either case, the node will later be compensated for both phases of validation via the fee or collateral collected from this transaction.

The expectation is that phase-2 failure should be rare, because a user submitting a transaction with failing scripts will lose ada while achieving nothing. This is locally predictable, and therefore a preventable event. The phase is a required safeguard to guarantee compensation for scripts’ potentially resource-intensive computation.

Let’s take a closer look at the specifics of each phase.

Phase 1

The first phase of validation must be simple. If this phase fails, a node does not get compensated for the work it has done, as it cannot accept processing fees from unprocessable transactions.

Phase-1 validation verifies two things: that a transaction is constructed correctly, and that it is possible to add it to the ledger. This validation includes the following checks and some additional ones:

• it pays the correct amount of fees and provides the correct amount of collateral (i.e. ada collected in the case of script failure, explained below)
• it includes all the data required for executing Plutus scripts
• it does not exceed any bounds set in the protocol parameters (on output sizes, etc.)
• its inputs refer to UTXOs existing on the ledger
• the stated computational budget for the transaction does not exceed the maximum resource limit per transaction
• integrity hash checks, etc.

Before adding an incoming transaction to the mempool (and eventually, to a block), a node must perform all phase-1 validation checks. If any of these checks fail, the transaction is rejected without being included into a block, and no fees are charged. In previous eras, this was the only validation phase, and Cardano handled all validation failures in this fashion.

Honest, non-compromised nodes are not expected to intentionally produce unprocessable transactions. Nodes can also drop connections performing adversarial dissemination of phase-1 invalid transactions.

Phase 2

The second phase of validation runs Plutus scripts, which can be more computationally expensive. Therefore, fees are charged following either a success or a failure in the second phase. Collected ada goes into the fee pot, and thus compensates nodes for the resources used in the validation process.

Successful phase-1 validation does not guarantee that all of the transaction’s actions are processable, only that collection of the collateral is possible. Phase-2 performs Plutus script validation, and the decision of whether to perform full processing or only collect collateral is made based on the outcome of validation:

• fully apply the transaction (the only possibility prior to Alonzo) – if the Plutus scripts validate all the actions of the transaction, or 

• collect the collateral ada and ignore the rest of the transaction – if one of the Plutus scripts fails 
.

Recall that script validation has a locally predictable outcome and is guaranteed to terminate. Users can locally check script validation outcomes, and there will be no disagreement between honest nodes on how to process a given transaction and the scripts therein.

Collateral

If scripts don't validate, we still need to compensate the nodes for their work. But we can't just take money from the transaction inputs, because those might have been locked with scripts - those that failed! So instead, Alonzo introduces a special provision for this. The collateral of a transaction is the amount of ada that will be collected as a fee in case of a phase-2 script validation failure. In a processable transaction, this amount must be at least a certain percentage of the transaction fee, specified in a protocol parameter.

This amount is specified at the time of constructing the transaction. Not directly, but by adding collateral inputs to the transaction. The total balance in the UTXOs corresponding to these specially marked inputs is the transaction’s collateral amount. These UTXOs must have public key (rather than script) addresses and contain no tokens other than ada.

The collateral inputs get removed from the ledger UTXO only if any script fails phase-2 validation. If all scripts pass, the specified transaction fee amount gets collected, as in previous eras. In particular, the amount comes from the regular, non-collateral inputs, and the collateral inputs are simply ignored. And, good news! It is permitted to use the same inputs as both collateral and regular, since only one of the two sets ever gets removed from the UTXO.

The signatures required to validate the spending of collateral inputs also play an important role in maintaining the integrity of a transaction. They do so by preventing adversaries from altering its contents so that it continues to be processable but fails phase-2 validation. An example of this would be an adversary replacing a redeemer. Collateral key holders’ signatures are required to make such a change. The collateral key holders are also the only users who stand to lose any ada if script validation fails.

Since script evaluation is deterministic, the collateral key holders are able to check locally whether the transaction will pass phase-2 validation on-chain before they sign it. If it does, then they can be sure it will also do so on-chain, and they will definitely not lose their collateral. A user acting in good faith should never lose their collateral. It also means that they can reuse the same collateral inputs for multiple transactions, and be sure the collateral is not collected.

Now that we have launched the public Alonzo testnet, we welcome all users and developers to assess it by building and executing Plutus scripts. You can find out more information in the dedicated Alonzo testnet repository, or discuss Plutus and Alonzo topics with our diverse community.

As the Alonzo hard fork brings core Plutus smart contract capability to Cardano, the ledger evolves to meet the growing need for the deployment of decentralized solutions. Cardano ledger design focuses on high assurance, security, and proven formal verification. In alignment with this strategy, it is also important to ensure that transaction processing is deterministic, meaning that a user can predict its impact and outcome before the actual execution.

The ability to guarantee the cost of transaction execution, and how the transaction behaves on the ledger before it is submitted, becomes even more prominent with the introduction of smart contract support. Unspent Transaction Output (UTXO)-based blockchains, like Cardano, provide such capabilities. Account-based blockchains, like Ethereum, are indeterministic, which means that they cannot guarantee the predictability of the transaction’s effect on-chain. This presents risks of monetary loss, unpredictably high fees, and additional opportunities for adversarial behavior.

In this blog post, we take a closer look at the benefits of Cardano’s deterministic design that allows for secure transaction and script evaluation before execution. In the following blog post, coming later this week, we discuss the two phases of transaction validation on Cardano.

What is transaction determinism and why is it important?

Determinism, in the context of transaction and script processing, is a synonym for predictability. This means that a user can predict locally (off-chain) how their transaction will impact the on-chain state of the ledger, without:

• unexpected script validation outcomes or failures
• unexpected fees
• unexpected ledger or script state updates.

A transaction in a deterministic system might yet be rejected, even if constructed correctly. Rejected means that the transaction could not be applied to the ledger at all, therefore having no effect on its state, so no fees are paid. The reason this would happen is due to ledger changes caused by other transactions processed between the time when the initial transaction is constructed and the time it is processed. This can happen even with simple transactions. For example, another transaction might spend a UTXO that a user was also planning to spend. Determinism ensures that, whenever a transaction is accepted, it will only have predictable effects on the ledger state.

Addressing the issue of indeterminism

Indeterminism means that we cannot predict what effects a transaction will have on the ledger before execution. When designing the ledger, as well as a smart contract interpreter, it is important to foresee conditions in which indeterminism might occur, and make design decisions to avoid them. One of the main hazards in such a case is access to mutable ledger data, that is data that can be changed or altered. When the changes a transaction or a smart contract make to the ledger depend on its state at the time of processing, rather than only the contents of the transaction, indeterminism might become an issue.

Ethereum is notably susceptible to this problem. For example, gas prices, or a decentralized exchange (DEX) rate can fluctuate between the time a user submits a transaction and the time it gets processed. This results in unexpected gas fees, or price changes of assets being purchased. Or a script might simply fail, resulting in high execution costs (hundreds of dollars) and no other effect. This could occur, for instance, if the funds available to cover the gas costs run out mid-execution. Deterministic ledger design eliminates these possibilities.

Other possible sources of indeterminism include allowing scripts to see:

• data in the block containing the transaction, but not included in any transaction, e.g., system randomness, block header, or the current slot number
• data altered or substituted by an adversary, which might change the outcome of script validation, while the transaction itself remains processable.

In most systems, there are ways to mitigate these issues with improved script-writing practices, or layer-2 solutions. Cardano is designed to guarantee predictable outcomes for all scripts and transactions.

How basic UTXO model benefits in terms of determinism

The Cardano ledger is built on a UTXO accounting model, which means that assets are stored on the ledger in unspent outputs, rather than in accounts. Each of these outputs specifies quantities of assets stored therein, together with its address. Unspent outputs are immutable, so a transaction might consume the entire output, but it cannot alter it.

To transfer assets, a transaction consumes one or more outputs and creates new ones, which, in total, contain the same quantities of assets as the ones consumed. These quantities -and their UTXO addresses- are specified in the outputs of the transaction. The only way a transaction can influence the effect of another transaction applied to the ledger is by spending the same UTXO as the later transaction attempts to spend, thus causing the node to reject it. This is the key feature on which the UTXO model relies for maintaining determinism.

A UTXO ledger has both benefits and drawbacks over the account-based model. The latter will encounter fewer instances of transactions blocking one another, for example. Unlike UTXOs, accounts are mutable ledger data. So a transaction might see, for example, a different quantity of assets in an account, depending on whether it was processed before or after another transaction that updates that same account. This circumstance might not cause the transaction to be rejected, but it could result in different – and unpredictable – changes to the ledger.

Spending a UTXO is just one example of an action a transaction can take. Next, we explain what transaction actions are, and how they can be validated. The most significant set of changes introduced in Alonzo are changes to the process of action validation.

Validating actions with signatures and scripts

An important aspect of processing a transaction is validating the actions it is taking. A transaction is taking an action when it contains data in the specific field to that action. For example, a transaction is spending UTXO U when it contains a reference to U in its input field, and it is minting a token X when its mint field contains X.

When the node processes a transaction, it verifies whether it can perform the action it intends to. For this, the author of the transaction must provide relevant pieces of data, e.g., scripts, redeemers, or signatures. A common example of an action that requires validation is spending a UTXO locked with a public key. The transaction must provide a signature from the corresponding private key to perform this action.

Cardano uses scripts to validate actions. These scripts, which are pieces of code, implement pure functions with True or False outputs. Script validation is the process of invoking the script interpreter to run a given script on appropriate arguments.

Script validation can be performed for the following actions:

• Spending a UTXO locked by a script address: the script that is run is the one whose hash forms the address.
• Minting a token: the script that is run is the one whose hash forms the policy ID of the token being minted.
• Reward withdrawal: the script that is run is the one whose hash forms the staking address.
• Applying a certificate: the script that is run is the one whose hash forms the certificate author’s credential.

Besides letting the node know which script to run, all transaction actions indicate how to assemble arguments passed to that script.

Cardano’s multi-asset ledger (Mary) supports simple multisig and timelock scripting languages. These allow users to specify signatures required to perform an action (such as spending a UTXO or minting a non-fungible token (NFT)), and the time interval in which it can be performed. A timelock script can never see the actual slot number in the transaction that includes it. Timelock can only see the validity interval of the carrying transaction. Allowing a timelock script to see the current slot number (i.e., data coming from the block, rather than the author) would break determinism. This is ensured by the fact that a user cannot know the exact slot in which the transaction gets processed, and therefore they cannot predict how the script will behave.

Mary scripts, unlike Plutus contracts in Alonzo, are very limited in what they can express. The Alonzo hard fork ushers in a new era of powerful, stateful contracts that do not compromise the deterministic ledger property.

Plutus scripts

Alonzo introduces a new approach to transaction validation on Cardano due to the implementation of Plutus scripts. The extended unspent transaction output (EUTXO) model, deployed as part of Alonzo, provides the ledger infrastructure to support Plutus contracts. Below, we provide a high-level overview of ledger and transaction changes. For more details about working with the ledger and Plutus scripts, check out the Plutus Pioneer program!

Alonzo changes the data on the ledger as follows:

1. Plutus scripts can lock UTXOs.
2. A new component, added to the contents of the output parts of UTXOs, enables script state-like functionality. In addition to assets and an address, a UTXO locked by Plutus scripts also contains a datum. A datum is a piece of data that can be thought of as an interpretation of the script state.
3. There are a number of new protocol parameters used to impose additional validation requirements on transactions. These include upper limits on computational resources that scripts can consume.

To support Plutus scripts, transactions have been upgraded as follows:

1. For each of its actions, the transaction now carries a user-specified argument, called a redeemer. Depending on the script, a redeemer can serve a different purpose. For example, it can act as the bid the user places in an auction, or the user’s guess in a guessing game, among many other functions.
2. The transaction specifies computational execution budgets for each script.
3. To ensure that a transaction can pay its execution fee, Alonzo introduces additional pieces of data, which we’ll discuss in a follow-up blog post.
4. Transactions contain an integrity hash, needed to ensure that it has not been compromised, outdated, etc.

There are also some changes to the specifics of Alonzo transaction validation as compared to Mary. For each action, the node assembles script arguments expected by the Plutus interpreter, including:

• the datum
• the redeemer
• execution budget
• a summary of the transaction.

The node performs new, Alonzo-specific checks that ensure the transaction is constructed correctly. For example, it must not exceed the maximum execution resource budget. It also invokes the Plutus script interpreter to run the scripts.

Datum objects vs script state

Like mutable accounts, mutable script state falls squarely into the ‘mutable ledger data’ category of indeterminism sources. We already saw that the UTXO model avoids the mutable accounts indeterminism issue. It can also help us reimagine the concept of script state in a way that maintains determinism. If a UTXO is locked by a Plutus script, that UTXO’s script code is associated with its address. The state-analog of this script is the datum stored in that UTXO. When a transaction spends that UTXO, it gets deleted from the ledger, including the datum. However, the contents of the Plutus script could enforce that the transaction carrying it must also create a UTXO containing a specific datum that can be viewed as the updated script state.

Script execution budget

The non-deterministic gas model can charge users unpredictably large fees. In Cardano scripts, this source of indeterminism is addressed by requiring that the resource budget itself, as well as the fee required to cover this budget, are included in the transaction. In Alonzo, a user can predict both locally when constructing the transaction. Script execution necessarily returns either True or False, and will not loop indefinitely. The reason for this is that every operation a script performs takes a non-zero amount of resources, which are tracked by the interpreter. If the budget specified by the transaction is exceeded, script execution terminates and returns False.

Transaction validation in Alonzo

Addressing the possible sources of indeterminism, the following key points make the outcomes of script and transaction validation predictable:

• the script interpreter will always terminate and return the same validation result when applied to the same arguments
• a transaction necessarily fixes all arguments that will be passed to the script interpreter during validation
• a transaction specifies all the actions it is taking that require script validation
• compulsory signatures on a transaction ensure that it cannot be altered by an adversary in a way that causes scripts to fail
• applying a transaction in the EUTXO ledger model is deterministic.

The last point is largely inherited from the UTXO model, as Alonzo ledger protocol updates remain, for the most part, consistent with updates in previous eras (including the delegation scheme, etc.). After the Alonzo upgrade, script validation failure or success does affect how a transaction is processed (more about this in part 2!). However, the True or False outcome, as well as ledger changes associated with either outcome, are predictable for a given transaction.

The deterministic behavior of Cardano’s script and transaction validation is not a natural outcome of using the EUTXO model. To ensure this property, the IOG team had to carefully track the source of every piece of data which a script is allowed to see.

The deterministic evaluation property is formally specified in the Alonzo specification, and the IOG team has also sketched proof that the interpreter gets only those arguments that would not break the property.

In our second blog post, we’ll take a closer look at the 2-phase validation process of Cardano transactions. So, keep an eye out later this week for part two.