At the Cardano Summit, IOHK announced a collaboration with Ergo, Nervos, and Topl to create the UTXO alliance. Today, we’re delighted to welcome a new alliance partner – Komodo.

Komodo is an open-source technology provider that offers all-in-one blockchain solutions for developers and enterprises. Komodo works closely with organizations that want to launch branded decentralized exchanges, cross-protocol financial applications, and independent blockchains. Komodo's flagship end-user application AtomicDEX is a non-custodial multi-coin software wallet and atomic swap-powered decentralized exchange rolled into one app. AtomicDEX and its underlying technology – Komodo AtomicDEX API – is compatible with 99% of cryptocurrencies in existence and offers the widest cross-chain, cross-protocol trading support in the entire blockchain industry.

“UTXO blockchains lay the basis and undisputed foundations of today’s blockchain industry. UTXO technology reflects Satoshi Nakamoto’s core vision of ultimate (financial) liberty,” said Komodo business development leader, Kadan Stadelman. “On behalf of Komodo Platform and the AtomicDEX team, I am honored to join the UTXO alliance to uphold and advance this vision. I am certain that together with other alliance members, we will bring this technology to the next level. All for one and one for all.”

The UTXO alliance will facilitate cross-ecosystem initiatives to extend the capabilities of UTXO in terms of smart contract functionality. Teaming up with other blockchain industry projects, the shared objective is to foster and support further research, development, and education across the entire space.

The goal of the UTXO alliance is to drive continuous innovation of the UTXO model in terms of interoperability, scalability (sharding, state channels), and smart contract solutions. Enhancing these solutions and driving key initiatives to build bridges between blockchains powers fair and accessible global finance for everyone. This also establishes a collective effort to enforce the development and functionality of UTXO-based ledgers. Other projects using this model include NEO, Bitcoin, and its derivatives like Bitcoin Cash, Litecoin, and Zcash.

Why UTXO matters

The unspent transaction output (UTXO) accounting model guarantees security, data privacy, and scalability at the core of financial activities. UTXO models foster scalability, as multiple UTXOs can be handled simultaneously, and ensure enhanced security as the overall stake is not aggregated into a single account.

UTXO is a more secure alternative to account-based models (used by Ethereum, for example). Unlike UTXO-based ledgers, account-based blockchains track the overall balance, and the same address is used every time a transaction is made. This is vulnerable to hacks and hinders scalability, as transactions are processed sequentially, rather than in parallel.

Cardano’s extended UTXO (EUTXO) model, for example, supports multi-assets and smart contracts and enables arbitrary logic in the form of scripts. These scripts can be split across different branches enforcing more parallelism and higher scalability.

Alliance member Nervos is developing a permissionless, layer 1, open-source, proof-of-work blockchain protocol focused on creating the foundations for an interoperable universal public network.

“Implementing the ‘separation of duties’ principle, Bitcoin’s visionary UTXO model is naturally more scalable and prone to attacks than the account model,” said Ren Zhang, lead researcher at Nervos. “Many projects sharing this vision provide unique perspectives to extend UTXO’s possibilities. The UTXO alliance enables interoperability and coevolution of its members, providing the world a superset of our advantages.”

Manuel Chakravarty, Lambda scientist and Plutus architect at IOHK added:

The UTXO ledger model, battle-tested by Bitcoin, remains the gold standard for security and scalability. The UTXO alliance is an important step towards ensuring that it will be the gold standard for interoperability, too.

Focusing on interoperability, programmability, and scalability

Centralized finance has been the centerpiece for financial operations for decades. While such a system has served us well enough in general, it still suffers from a reliance on a central authority, exorbitant transaction fees, and unnecessary delays, complexity, and costs in making international payments because of regulatory restrictions. It’s time for change.

Interoperability

Blockchain technology addresses the challenges of centralization by enabling reliable peer-to-peer transactions based on cryptographic proof rather than relying on costly intermediaries. Many blockchain projects have emerged to provide a secure and decentralized environment for financial transactions. These projects vary in terms of consensus algorithms, accounting models, or smart contract applicability focusing on particular use cases (such as finance, data traceability, supply chain management, etc).

Growth is inevitable. However, the speed at which the blockchain landscape matures is challenged by siloed ecosystems and disparate governance rules, technology versions, or functionality support.

As Romain Pellerin, IOHK CTO, said at the Summit:

Mainstream blockchain adoption will pass only through the interconnection of networks, similar to how the Internet was built by the interconnection of intranets and extranets.

So, today, it is important to ensure that the whole industry is driving towards interoperability. Users should be able to transact with each other without being limited to a certain ledger, smart contracts should be supported within different environments, and decentralized applications (DApps) should have cross-platform compatibility. Only such an approach will allow the blockchain industry to reach the full potential of its capabilities, driving further adoption.

Programmability

The UTXO alliance is also focused on blockchain programmability for the creation of DApps and smart contracts. In fact, the design of new languages is required in order to adapt to the specific transaction and data storage management (Ergo’s and Cardano’s EUTXO, or Nervos’ cell model, for example) of the UTXO model. The founding members of the alliance have developed Antara, CKB-VM, ErgoScript, and Plutus as their smart contract languages. Alliance members are sharing knowledge and collaborating in the development of those technologies to rapidly scale the number of use cases that can be run on UTXO-based blockchains.

Also, those languages are built as domain-specific languages (DSLs) on top of common programming languages including Scala, Haskell, C, JavaScript, Go, Rust, etc. However, in certain cases, those common languages do not offer the security or ease of use that smart contract developers require.

To ensure enhanced security and code verifiability, IOHK has chosen Haskell as the programming language for Plutus smart contracts. It is the most widely used functional programming language for application development. Haskell is simple, secure, and formally verified. In terms of adoption, it is suitable for a wide range of financial use cases, while allowing to move funds rapidly, get the right results, and ensure scalability. This programming style fits well within the UTXO model with regard to state distribution and parallelization for enhanced scalability.

Nervos is also working on alternative provably secure programming options that use RISK-V compilers to support common programming languages with CKB-VM. Topl, on the other hand, has been working on a chain program engine proof of concept, which is basically an abstraction layer on top of the UTXO model that allows working with shared state execution environments. It uses a pointer registry and a series of UTXOs (represented as atomic data elements in ledger state -i.e., boxes-) to reconstruct an execution context for evaluating program method call transactions.

Taking into consideration different development efforts, the UTXO alliance will be exploring the best-case scenarios to create a unified smart contract ecosystem where a variety of programming languages can be compiled and used on different blockchain platforms. This will be instrumental in ensuring better interoperability between blockchains.

Scalability

As a network grows, it is also important to take into account its scalability capability in terms of transaction processing and throughput. The UTXO model is different from the account-based one, as it functions based on the local state, and thus requires a different programming approach.

These two models have different properties and offer a different set of trade-offs, different pros and cons. The UTXO model ensures determinism, predictability and scalability by managing local states (the local portions of the overall graph of transactions) while the account model facilitates the development of use cases that rely on the global state (the whole graph of transactions needs to be processed before validation).

Hence, the UTXO model offers valuable properties of ensuring the execution of transactions and contracts prior to their submission on the chain with no surprises in terms of fees or validation. Also, the UTXO model can provide better scalability as it is simpler to shard a graph of transactions by definition by dividing into a set of sub-graphs.

It is also easier to detach a particular transaction or set of transactions (that transport data, scripts and assets) to continue activity off-chain before coming back with a result on-chain which ensures scalability by off-loading activities from the mainchain. IOHK, for example, has developed Hydra state channel solutions that increase the system throughput and allow running multiple operations in parallel without compromising scalability. You can find out more about scalability by reading about concurrency on Cardano and the Hydra approach.

Combining forces for the common goal

The UTXO alliance collaborates to advance the UTXO model while developing a universal UTXO standard. It aims to provide ada holders, cryptocurrency users, enterprises, and the developer community with a range of solutions that do not lock them into a single standard. For this, the alliance will be conducting academic research and releasing a number of papers that underpin secure and scalable smart contract development based on the UTXO model.

While interoperability is key, it is also crucial to provide blockchain solutions for increased funds security, scalability of transaction processing, and, of course, extended functionality granted by smart contracts.

Alliance member Topl has developed a blockchain built to be an impact monetization engine. James Aman, Topl founder and CTO said: “Extended UTXOs enable novel methods of computation in DLT systems that bridge the gap between hard-coded protocol behavior and smart contracts. EUTXOs enable users to engage in complex interactions while retaining full local verifiability even from light clients.”

To enable the possibility of utilizing various features in a blockchain-agnostic way, the alliance is committed to addressing such instrumental questions as:

• how to seamlessly transfer data between different blockchain environments
• what is the ideal size of data to be used in transactions
• what should be the speed of data processing
• the transaction cost, etc.

Thus, the alliance focuses on the mechanism that enables seamless and secure transactions between different blockchains to foster the greater adoption of blockchain technology. This will also drive the development of solid DApps and DeFi solutions.

Alex Chepurnoy, the co-founder of alliance member Ergo, added: “While it is well-known that UTXOs are better for blockchain scalability and simpler off-chain protocols, the extended UTXO model also allows for novel on-chain DeFi constructions with interesting properties.”

This is only the beginning, and we are currently looking into collaborations with more ecosystems to pioneer improvements of the UTXO model, investigate how the common knowledge and technology stack can improve scalability properties, and contribute to open-source research. We’ll keep you posted as the alliance grows.

Visit the UTXO alliance website to find out more, join the alliance or contribute to the research.

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.