The Alonzo upgrade has enabled the deployment of smart contracts, decentralized applications (DApps), and other applications on top of Cardano. All this is hugely significant for Cardano, as it will open Cardano to a whole new developer community whose creative drive will boost Cardano's utility and adoption.

Any new application ecosystem presents an enticing smorgasbord of exploration. Equally, an emergent ecosystem faces two key challenges at the beginning: discovery and quality assurance. Users need to be able to find the products they want to engage with, and do so with the reassurance of a certain baseline level of quality.

The influx of new, third-party applications also poses the inherent risk of inappropriate or malicious material, or content that it's simply not up to standard. So addressing discovery and quality assurance issues is key to early ecosystem growth.

We’ll offer a deeper dive into this important topic this weekend at the Cardano Summit. There, we shall introduce a certification program to assess applications developed on top of Cardano. And also those on the upcoming dAppStore we are developing.

DApp discovery on Cardano

The dAppStore – and we’ll preview a prototype at the Summit – is where developers will be able to upload their DApps running on Cardano and make them available to others in the. The store will provide a trusted, and democratized environment for developers to publish their DApps without facing censorship.

The Plutus dAppStore specifically addresses two barriers to entry:

• There currently is no formal discovery process for a DApp. Almost all discovery happens through organic or word-of-mouth means, or through social media marketing
• For end users, there is no consolidated view of all DApps available in a given ecosystem

Users will be able to access the Plutus dAppStore using a web browser. Think of the Plutus dAppStore as a 'storefront' for Cardano. The store displays the range of things that you can do on Cardano. A certification program gives users assurance about the behavior of any apps that they use, through automated logic checks, manual smart contract auditing, and formal verification.

Any DApp can exist on the store, whether certified or uncertified, but we will provide users with clear information about a particular DApp's certification status. The dAppStore seeks not to act as gatekeeper (or judge) but rather to provide a platform for transparent user assessment.

The crucial role of certification

The dAppStore is a shopfront. But aside from community validation, it offers no ‘baked in’ assurance. So this is where the second element comes in. The role of our certification program is the prevention of code-level security vulnerabilities. We shall achieve this by deploying different levels of ‘defense’.

There will be several tiers. At the simplest level, automated logic checks will enable us to detect certain types of malicious code. For example, these will be able to check if the contract does not contain a way for locked up funds to be recovered. In a well composed contract, locked funds need to be retrievable.

Beyond that, manual smart contract auditing will help us verify any DApp’s integrity. Ultimately full formal verification will test the mathematical model to prove that a smart contract satisfies the formal specification of its behavior.

Of course, any certification program is only as good as those who implement and run it. For this reason, we are partnering with some of the leading names in the functional programming space, who you will meet at the Summit.

Building on a secure foundation: Cardano itself

This certification effort builds on a blockchain that already provides more assurance than others like bitcoin or Ethereum. For example, tokens are built into the architecture of Cardano itself, rather than having to be provided by contracts, such as ERC20 on Ethereum. This eliminates any issues created by copying and modifying a contract to implement a new token.

Looking at the foundation of the chain, the Extended Unspent Transaction Output (eUTXO) accounting model is a fundamentally simpler – and more secure – model for a blockchain. Smart contracts in Plutus are functional programs, and the simple and verifiable semantics of functional languages underpins what we do with both automated testing and formal verification. We want to build a more secure foundation than other chains. Plutus is a functional language.

Also, Marlowe, our special-purpose language for finance, guarantees certain properties by design. For example, no Marlowe contract will retain assets after the contract has terminated. That is a property built into Marlowe, which does not require extra checks to be enforced. Because of its design, Marlowe also allows tools to automatically check that contracts have certain good properties by verifying every possible execution of the contract, without having to run it; this is something that general Plutus contracts cannot do.

Certification in the context of the Alonzo hard fork

At the Summit we’ll show examples of automated testing of smart contracts, which are components of DApps, rather than full DApps.

In the longer term, we would like to see user-designed tools, the deployment of those tools to the store, and the evolution of the Plutus dAppStore to include new features such as upvoting, reviews, and even Atala PRISM integration etc., giving users the opportunity to feed back on the range of DApps in the store.

Through our work on the Alonzo testnets, the Plutus Pioneer program, and of course Project Catalyst, we have already seen a host of projects starting to build on Cardano. As these projects start to come to market over the months ahead, user discovery and user trust in those DApps will be key. We are working with an open, decentralized ecosystem, so the usual rules of caveat emptor and ‘Do Your Own Research’ will of course continue to apply. But helping drive higher standards in certification and assurance will be key to accelerating the growth of a successful ecosystem on Cardano and ultimately, the widest possible user base.

Simon Thompson and Fernando Sanchez also contributed to this piece.

Join us at the Summit on 25-26 September to learn more about this exciting new initiative and see a demo of the dAppStore prototype.

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.