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.

Cryptocurrency volatility is one of the obstacles to its wider adoption. Blockchain technologies provide benefits such as transparency, data immutability, and proven security of financial operations. Yet, it is harder than fiat currencies to predict how the market will behave, or forecast the value of a digital currency. This hinders using cryptocurrencies as accounting and exchange units in daily operations.

A stablecoin is a cryptocurrency pegged to a basket of fiat currencies or a single currency (eg, USD or EUR); commodities like gold or silver; stocks; or other cryptocurrencies. Stablecoins include mechanisms that maintain a low price deviation from their target price and so are useful to store or exchange value, as their built-in mechanisms remove the volatility.

Some stablecoins lack transparency and liquidity of their reserves, which compromises their price stability. To address these challenges, IOG has teamed up with Emurgo, another of the three founding partners of Cardano, and the Ergo blockchain, which uses UTXO-based accounting like Cardano, to work on a stablecoin contract called Djed. Djed is based on algorithmic design. This means it uses smart contracts to ensure price stabilization, and that the coin will be useful for decentralized finance (DeFi) operations.

How stablecoins work

Different mechanisms contribute to the stability of the coin’s value and help eliminate price variations. These mechanisms are underpinned by the economic principles of supply and demand.

A common mechanism is backing the stablecoin by a reserve of the currency used as the peg. If demand is higher than the supply of sell or buy orders, this supply should be increased to avoid fluctuations in the price. Typically, stablecoin reserves are not stored in cash. Instead, they are kept in interest-bearing financial instruments such as bonds. The returns on these provide revenue for the operator.

As long as the stablecoin is fully backed by reserves in the currency to which it is pegged – and the operator can react quickly to variations in demand – price stability is maintained.

Common risks

Stablecoin reserves are commonly associated with investments. The lack of liquidity of these investments may prevent the operator from reacting quickly to demand. This compromises stability in the short term.

A drawback of fiat-backed stablecoins is that they require trust in the entities keeping the reserves. Lack of the reserves’ transparency or of the ‘full-backing’ claim, combined with inefficient stabilization measures, have already caused Tether stablecoin (USDT) to fall below $0.96, as shown in Figure 1.

Figure 1. Price of the Tether stablecoin (USDT) in the past three years

Issues of transparency do not arise when the backing asset is a cryptocurrency on a public blockchain. Furthermore, the use of smart contracts ensures efficient and reliable execution of stabilization measures due to its automated and secure mechanisms.

Enhanced stabilization mechanisms of Djed algorithmic stablecoin

Djed is a crypto-backed algorithmic stablecoin contract that acts as an autonomous bank. It operates by keeping a reserve of base coins, and minting and burning stablecoins and reserve coins. The contract maintains the peg of stablecoins to a target price by buying and selling stablecoins, using the reserve, and charging fees, which accumulate in the reserve, as shown in Figure 2. The ultimate beneficiaries of this revenue stream are holders of reserve coins, who boost the reserve with funds while assuming the risk of price fluctuation.

Figure 2. How Djed works

The Djed stablecoin is designed as an asset pegged to a fiat currency (USD), along with a governing algorithm. This approach provides a stable means of exchange. But Djed is not limited to being pegged to the dollar. It can work with other currencies, as long as there are oracles providing the contract with the corresponding pricing index.

The first formally verified stablecoin protocol

Djed is the first formally verified stablecoin protocol. The use of formal methods in the programming process has greatly contributed to the design and stability properties of Djed. Using formal techniques, the properties are proven by mathematical theorems:

• Peg upper and lower bound maintenance: the price will not go above or beyond the set price. In the normal reserve ratio range, purchases and sales are not restricted, and users have no incentive to trade stablecoins outside the peg range in a secondary market.
• Peg robustness during market crashes: up to a set limit that depends on the reserve ratio, the peg is maintained even when the price of the base coin falls sharply.
• No insolvency: no bank is involved, so there is no bank contract to go bankrupt.
• No bank runs: all users are treated fairly and paid accordingly, so there is provably no incentive for users to race to redeem their stablecoins.
• Monotonically increasing equity per reserve coin: under some conditions, the reserve surplus per reserve coin is guaranteed to increase as users interact with the contract. Under these conditions, reserve coin holders are guaranteed to profit.
• No reserve draining: under some conditions, it is impossible for a malicious user to execute a sequence of actions that would steal reserves from the bank.
• Bounded dilution: there is a limit to how many reserve coin holders and their profit can be diluted due to the issuance of more reserve coins.

Djed versions

There are two versions of Djed:

• Minimal Djed: this version is designed to be as simple, intuitive, and straightforward as possible, without compromising stability.
• Extended Djed: this more complex version provides some additional stability benefits. The main differences are the use of a continuous pricing model and dynamic fees to further incentivize the maintenance of the reserve ratio at an optimal level.

Implementations

IOG, Ergo, and Emurgo teams have been working on the implementation of the Djed algorithmic stablecoin contract earlier in 2021 to test different models.

The first implementation of a Djed stablecoin contract was SigmaUSD on Ergo. This was the first algorithmic stablecoin deployed on a UTXO-based ledger in Q1 2021. It had a fee of 1% for buying or selling operations, and an oracle that updated the exchange rate every hour. This initial version was subject to a reserve draining attack by an anonymous user who owned a large number of ERGs (Ergo’s native coin). The attack was ultimately unsuccessful, and it is estimated that the attacker lost $100,000.

To further discourage such attacks, this initial deployment of Minimal Djed was replaced by a version where the fee was set to 2%, the oracle updated every 12 minutes, and every oracle update was allowed to change the price by at most 0.49%, unless the price difference was greater than 50%. This provided stronger resilience against reserve draining attacks.

Djed has also been implemented by the IOG team in Solidity. One version uses the native currency of the Ethereum blockchain as a base coin, and another uses any ERC20-compliant token as a base coin. So far, these implementations have been deployed to testnets for Binance Smart Chain’s testnet, Avalanche’s Fuji, Polygon’s Mumbai, Ethereum’s Kovan, Ethereum’s Rinkeby, and RSK’s testnet.

Djed: Cardano implementation

The Alonzo update to Cardano will enable smart contracts using Plutus. Plutus is powered by Haskell, which guarantees a safe, full-stack programming environment.

Draft implementation of an earlier version of Minimal Djed is available in the Plutus language. In this implementation, stablecoins and reserve coins are native assets uniquely identified by the hash of the monetary policy that controls their minting and burning according to the Djed protocol. This implementation also assumes that oracle data such as the exchange rate is provided as signed data directly to the transactions, instead of being posted on-chain.

There is also an ongoing OpenStar implementation. OpenStar is a framework for private permissioned blockchains developed in Scala. The implementation of Djed using OpenStar follows the idea of off-chain smart contract execution to have a stablecoin on Cardano that does not depend on smart contracts executed on-chain.

To find out more about Djed stablecoin, see the recently published research paper or check out the presentation by Bruno Woltzenlogel Paleo, IOG technical director, at Ergo summit 2021.

We’d like to thank and acknowledge Bruno Woltzenlogel Paleo for his input to this article and support throughout the process of its creation.

At the start of March, we implemented Mary ‒ a multi-asset protocol upgrade that allows users to create unique tokens for transactions on Cardano. With the introduction of transaction metadata, then token-locking with Allegra in December, and native token creation, we are laying the foundation to establish Cardano as the leading smart contract platform.

Alonzo, our next protocol upgrade, will build on these capabilities. Implemented using our hard fork combinator technology, Alonzo will add support for smart contracts – digital agreements – to Cardano about four months from now. It will open up opportunities for businesses and developers, by allowing the creation of smart contracts and decentralized applications (DApps) for decentralized finance (DeFi).

When it came to naming these upgrades, we chose Allegra (Lord Byron's daughter) for token-locking, and Mary (the novelist and wife of Shelley) for multi-asset support. Alonzo comes from a more contemporary figure, Alonzo Church (1903-95). Church was a US mathematician and logician who worked on logic and the foundations of theoretical computer science. He is also known for inventing lambda calculus ‒ a formal system used to prove the unsolvability of the Entscheidungsproblem. Later, while working with fellow mathematician Alan Turing, they discovered that the lambda calculus and the Turing machine were equal in capabilities, demonstrating various mechanical processes for computations. One of the reasons for naming our smart contract upgrade after Church is that Plutus Core (the Cardano smart contract language) is a variation of lambda calculus.

Why smart contracts?

Smart contracts mark the next phase in Cardano's evolution as a worldwide distributed ledger. When supporting everyday business, a blockchain must guarantee that individuals can move their funds and pay for products in a secure way.

Smart contracts can be used to settle complex deals, hold funds in escrow, and secure movement of funds under predefined conditions. Cardano will allow DApps to interact with the ledger to record their activities and execute smart contracts. These digital agreements express the story of a transaction, specify where funds should go, and under what conditions they will be sent, executing a deal only when all the conditions are met. Alonzo will lay the foundation for Cardano to support such applications.

Addressing business needs with Alonzo

While multi-asset support allows users to create unique currencies that fuel business needs, Alonzo introduces a versatile platform for building smart contracts. It will be possible to work with collectibles, crowdfunding, or auctions, for example.

Areas of exploration might include the deployment of escrow-based decentralized cryptocurrency exchanges (DEX), or the creation of complex applications supporting centralized stablecoins (track-and-trace applications for product provenance within a supply chain, for example). With token-locking, users will be able to issue utility tokens with vesting periods, meaning that a number of tokens can be locked or frozen to be released after a specific time.

The scripting power of Plutus Core

With Alonzo, we are adding the necessary tools and the infrastructure to allow application development using the Plutus Platform.

Applying a rigorous approach based on formal methods and verification, Alonzo extends the basic multi-signature scripting language (multisig) used in Cardano Shelley. Multisig will be upgraded to the Plutus Core language for more powerful and secure scripting options. The Alonzo ledger implements the extended unspent transaction output (EUTXO) accounting model, using Plutus Core to provide powerful scripting.

A smart contract platform must be both secure and reliable. That’s why we chose Haskell as the basis for writing Plutus Core smart contracts. Haskell is a high-level language that developers will use to write code and then compile it to Plutus Core.

Haskell has been around since 1987, standing out from other programming languages for its high level of trust. Writing in Haskell ensures that smart contracts are programmed to do exactly what they are expected to and can be tested for accuracy before implementation. This means that smart contracts built on Cardano will be straightforward and resistant to vulnerabilities, which is crucial for applications that handle automated trading or move large funds around.

Tools and APIs

Developers will have functional tools to experiment with and customize transaction validation on Cardano. The API library will be extended to enable the deployment and operation of the Plutus Core code on Cardano while interacting with wallets and the ledger.

Deploying Alonzo is a complex process. Once functional smart contracts are running on the mainnet, we will continue improving the off-chain infrastructure to deliver software development kits.

Where are we right now?

Figure 1. Alonzo roadmap. The code will be frozen for four weeks before release

Throughout March and April, the IO Global team has been gradually combining the Alonzo rules with the Cardano node and ledger code. When Alonzo integration with the node is complete, Cardano will provide working API tools and command line interface (CLI) support.

From mid-April into early May, the team will continue working on Plutus development to launch a private testnet. During this phase, our partners (advanced developers) will be testing out the platform, creating and deploying non-fungible tokens (NFTs), marketplaces, or DApps running smart contracts on Cardano. This process will focus on step-by-step improvements to ensure that everything works efficiently.

In May, we’ll start working with our Plutus pioneers. These certified program trainees will continue testing the platform by writing Plutus applications and putting them into production for DApps and DeFi. During this phase, the team will be performing the ledger, node, and wallet backend integration. We will also be preparing and releasing documentation, including specification examples and developer guides.

May and June will be a time for quality assurance and testing with users, which will be followed by a feature freeze lasting for four weeks. This will provide crypto exchanges and wallets with the time to upgrade and prepare for the Alonzo protocol update. We expect the Alonzo upgrade (hard fork) to happen in late summer, and we will announce a firm date in April’s Cardano360 show.

For a more detailed roadmap, check out the March Cardano360 presentation by Charles Hoskinson.

These are exciting times and we encourage you to stay tuned. The next blog post will delve into the relationship between the Plutus concepts that underpin Alonzo development. Meanwhile, the developers’ website has more about programming with Plutus, Marlowe, and Glow.

The decentralization of Cardano puts responsibility for running the blockchain in the hands of stake pools. An essential element in this is reliable and effective connections between all the distributed nodes, and ensuring that the network is resilient to failure.

With the simpler Byron version of the blockchain, federated (OBFT) nodes controlled by the Cardano Foundation, Emurgo, and IOHK were wholly responsible for managing block production and network connections. This maintained the network, while building up a system of thousands of distributed nodes, operated by stake pools. To achieve decentralization, Cardano has now ended the prevalence of the federated nodes that have supported the system since its creation in 2017.

On December 6, 2020, we set the k parameter to 500 to expand the number of ‘viable’ pools and further promote decentralization. We have also gradually reduced d to put the power of block production entirely into the hands of the community. 100% of blocks are now being produced by the stake pool operator (SPO) community, which means that block production in Cardano is completely decentralized. These parameter changes support long-term chain sustainability and encourage the spreading of stake and potential rewards more evenly among stake pools.

In just over six months, we have evolved from a system reliant upon a handful of federated nodes, into a proof-of-stake system run by the community, with thousands of blocks produced every epoch by over 2,000 stake pools.

The network

Cardano’s networking layer is a physical infrastructure that combines nodes and their interaction into a unified system. The network distributes information about transactions and block creation among all active nodes. In this way, the system validates and adds blocks to the chain and verifies transactions. Thus, a distributed network of nodes must keep communication delays to a minimum, and be resilient enough to cope with failures, capacity constraints, or hackers.

Under the old federated system, nodes were connected by a static configuration defined in a topology file. Since the introduction of Shelley, the system has been functioning in a hybrid mode, where nodes connect to federated relays and to other SPO’s relays. This connectivity is partially manually constructed, however, SPOs can exchange block and transaction information without relying on federated nodes.

In his article 'Cardano’s path to decentralization', Marcin Szamotulski discussed the network’s design and explained Cardano’s approach to network decentralization with the advent of Shelley. Now that we have reached full decentralization in terms of block production, it is also essential that the network connectivity is decentralized too. Cardano will achieve this through a shift to peer-to-peer (P2P) connectivity.

P2P networking

At this point, we should talk about the network ‘stack’, a set of software tools recently enhanced by our engineering team to cope with a larger, more dynamic, and complex network.

P2P communication will enhance the flow of information between nodes, thus reducing (and ultimately removing) the network’s reliance on the federated nodes, and enabling the decentralization of Cardano. To achieve the desired resilience, IOHK’s networking team has been busy improving the network stack with advanced P2P capabilities. These improvements do not require a protocol change, but rather enable automated peer selection and communication.

The P2P networking is enabled due to the use of the following components:

Figure 1. P2P architecture

Let's take a closer look at the process of how node connections are established and see how the latest developments streamline data exchange between nodes.

Mini protocols

A set of mini protocols enables communication between nodes. Each protocol implements a basic information exchange requirement, such as informing peers of the latest block, sharing blocks, or processing transactions. Chain-sync, block-fetch, and tx-submission protocols have been used to distribute chains of blocks and transactions for node-to-node communication in the network:

• block-fetch draws information from the chain database.
• chain-sync synchronizes fetched data across the network.
• tx-submission2 consumes transactions from peer mempools and adds them to the local mempool, which enables peers to submit their transactions to the node. This is a modification of the current tx-submission protocol.

These mini protocols support the Ouroboros consensus protocol. To ensure optimal networking service, the team has implemented additional protocols:

• keep-alive: this ensures continuous connection between nodes and minimizes performance faults.
• tip-sample: this provides information about which peers offer better connectivity in terms of performance.

You can find out more about the network architecture and mini protocol examples on the Cardano documentation website.

Connection management

The networking service supports Linux, Windows, and macOS, but the number of connections supported by each operating system varies.

To avoid system overloading, a multiplexer combines several channels into a single Transmission Control Protocol (TCP) connection channel. This offers two advantages: One, bidirectional communication between peers (so any peer can initiate communication with no restrictions as both parties have read and write permissions within the same channel), and enhanced node-to-node communication without affecting performance.

The networking team has implemented a bidirectional-aware ‘connection manager’ that integrates with the P2P governor, which is currently undergoing final testing before deployment. Additionally, the multiplexer’s API has been upgraded to monitor new connections and protocols. This enhancement introduces more efficient connection management and improved issue tracking.

P2P governor functionality

The Cardano network involves multiple peer nodes. Some are more active than others, some have established connections, and some should be promoted to ensure the best system performance. As discussed in 'Cardano’s path to decentralization', peers are mapped into three categories:

• cold peers
• warm peers
• hot peers

To establish bidirectional connections between them, it is crucial that we know which connections are active.

Figure 2. Peer discovery on Cardano

The P2P governor manages connections and provides information on which peers are active and performing well. This feature promotes peer connections for enhanced system performance and also provides excellent visibility by building and maintaining a connectivity map of the entire network. The governor will simplify the process of connection definitions by handling these automatically so a few central stake pools no longer have to configure them manually. The governor promotes or demotes peers between cold, warm, and hot states, and also interacts with the connection manager to open new connections or reuse existing ones.

P2P deployment roadmap

The IOHK networking team is in the final stages of quality testing the P2P governor integration with the node. After this, the team will extend the network stack with more protocols – gossip, in particular, which will provide seamless data exchange between peers and help construct a decentralized communication map.

These technical upgrades allow us to simplify Cardano node interfaces and improve the system’s configuration. When testing is finalized, all SPOs will be able to update and simplify their configuration preferences for enhanced connectivity.

This involves the following stages before full P2P deployment:

Figure 3. P2P deployment roadmap

For a walkthrough of the plan from chief architect Duncan Coutts, check out this video from the March Cardano360 show.

While governance played an important role in the network establishment, maintenance and support, only with decentralization we can achieve true network sustainability to ensure equal opportunities for all stake pools. Thus, the goal of stack improvements is to allow all stake pools to run the same configurations, establishing equal capabilities within a decentralized environment.

We’ll keep providing more development updates in this blog, and you can also follow Cardano status updates to learn about recent improvements and developments.

Goguen is Cardano’s development theme that focuses on utility, smart contract support, and native token issuance. While delivering it as a system of interactive components, we are gradually adding all the building blocks to add smart contracts to the Cardano platform.

Goguen brings native token support along with Plutus and Marlowe to help develop the smart contracts that are essential to establishing a global, decentralized financial system. To lay the groundwork, we have introduced transaction metadata, upgraded the ledger to support token locking (which is essential for complex smart contracts), and will soon deploy native token support for multi-assets. We are also building devnets to bring in other developer communities.

Now, we have refreshed and upgraded the Plutus Playground and we are encouraging developers to contribute to its growth by testing the pre-release version.

What is the Plutus Playground?

Plutus Playground provides an environment for writing and testing smart contracts before they are released on the Cardano blockchain. Plutus Core, which is the smart-contract language embedded into the ledger, is based on Haskell formal programming principles and allows developers to write high-assurance applications that interact with Cardano. Haskell was chosen as the basis for the Plutus Platform because it stands out from other programming languages for offering the ability to write more secure code. Using Haskell for smart contract deployment ensures that contracts are programmed to do exactly what they are expected to and can be tested for accuracy before implementation.

As well as providing a web-based simulator for writing and executing smart contracts, the new Plutus Playground also allows users to access popular smart contracts that have already been written. An early version was previewed at PlutusFest in December 2018. Since then, the project has expanded considerably and this new release of Plutus Playground reflects that.

Who is it for?

Plutus Playground is for people creating decentralized applications (DApps), and smart contract programmers who wish to work with Cardano. Plutus will become a platform for building DApps for supply chains, track and trace, medical records, identity voting, property registration, P2P payments, and financial systems. Thus, it will serve the needs of audiences such as:

• companies, large and small
• governments
• the Cardano community and ada holders
• entrepreneurs.

Plutus Playground features and improvements

So, now is the time for developers to start building Plutus contracts and testing them prior to the deployment of Plutus on the Cardano mainnet later this year. Plutus Playground works through your web browser and there is no need to install software. There are tutorials on compiling and simulating smart contracts written by the Plutus team.

Improvements have been made to the backend software, reported issues have been addressed, and the interface is even better.

Figure 1. The old Plutus Playground editor (left) compared with the new interface, which is now available

As with the existing Plutus Playground, the interface is split into three sections:

• editor
• simulation
• transactions.

The simulator shows how a contract will behave on the Cardano blockchain. An important aspect of this is that it can act as a training tool for people who do not have advanced developer skills because it demonstrates the working principles. Users can define and modify the wallets that interact with a contract, as well as the actions that affect the outcome. The results can then be evaluated to see what happens on the blockchain and how transactions occur.

The Plutus Playground offers a choice of keyboard setups. Developers can choose between Vim and Emacs options or stick with the default keyboard.

We have also refreshed the look and feel with UX improvements. Finally, the simulator is more realistic in the way it runs Plutus applications, and as previously, it can be linked with GitHub accounts to save contracts and any work in progress. You can find a full technical walkthrough here.

How to get involved

We are now encouraging experienced developers (and less experienced ones too!) to test Plutus Playground before the final offering. If you are interested in smart contracts and wish to get involved, we are eager to hear your feedback.

The Playground refresh goes live today at https://playground.plutus.iohkdev.io/. You can join Plutus discussions at the Cardano Forum and visit the Plutus GitHub repository. For access to additional support and resources, register your interest by filling out this Typeform for us to add you to our Slack community.