Cardano is designed to serve millions of users in a globally distributed way. As with any other decentralized blockchain, this means that we need to produce a predictable and consistent supply of new blocks that collectively grow the chain and transparently record transactions between users. In order to ensure that new blocks are propagated across the network as a whole in an effective and secure way, it is important that the system consumes computation, memory, storage, and network resources efficiently.

Flexibility is key, so an important feature of the Cardano protocol is that it has been architected with true scalability in mind. This isn't just about the longer-term ability to provide the infrastructure into a truly global, fully decentralized operating system; its parameterization approach is also designed to flex and adjust to pricing fluctuations, network saturation, or increased demand, for example. A number of protocol parameters are provided that allow the system behavior to be tuned without the need for a hard fork. Even then, more significant upgrades that do require this can be deftly managed using our hard fork combinator technology (HFC). Together these are significant differentiators for Cardano which give us robustness and reliability today, and highly agile upgrade paths as the network grows and usage evolves.

Cardano’s roadmap was also conceived in a series of stages that would take us step by step toward our ultimate destination. Byron was about basic transactional capability within a federated network. This gave us the ability to start building a community and partnerships while working on the next stage. The Byron reboot gave us the firm foundations to build out further capability, while Shelley introduced stake pools, further expanding the community and introducing 100% decentralized block production.

This year, we have introduced a number of new, highly-anticipated features. Since early 2021, with the Mary era, Cardano has supported multi-assets and non-fungible token (NFT) creation on the ledger. With low fees and no need for smart contracts, we have seen an explosion of activity in this exciting area. September’s Alonzo upgrade has brought support for Plutus smart contracts that enable the development of a wide range of decentralized applications (DApps). It's relatively early days for smart contracts, but with dozens of projects working on DApps and a number getting close to the deployment stage, things will soon start to accelerate. These new capabilities influence how the ledger processes new scripts and transactions, and place new demands on the available resources. As activity grows, our architecture will allow us the agility to flex and adapt as required.

Network capacity

Networking lies at the heart of all Cardano operations. The Cardano network distributes transactions and blocks across globally distributed nodes that produce and verify the blockchain. This is called data diffusion, and it is essential to provide the needed information to nodes for the consensus algorithm to make its decisions. These decisions drive the chain forward, as a consensus between the nodes ensures that all transactions are verified, validated and thus can be transparently included in a new block.

Cardano is based on the decentralized Ouroboros Praos consensus protocol. Cardano smoothly transitioned to Praos from the previous federated Ouroboros Classic protocol via a series of changes to a protocol parameter d. Ouroboros Praos establishes enhanced security guarantees and has been delivered with peer-reviewed research papers presented in top-tier cybersecurity and cryptography conferences and journals.

Networking performance impacts how fast the system works as a whole. This includes such measures:

• throughput (volume of data transferred)
• timeliness (the block adoption time)

These two requirements are in tension with each other. We can maximize throughput when the generated blocks are most efficiently used. This, in turn, implies sufficient buffering to hide latency, which mitigates the consequences of a globally distributed system.

More buffering can often imply better block (and network) utilization, but it comes at the cost of increased delay (time to adoption in the chain) when the system is heavily saturated.

Block budget

To understand how fast transactions and scripts can be executed on Cardano, we should first define the notion of the block budget. The overall size of a block is currently limited to a maximum of 64 KB, representing a balance between ensuring good network utilization and minimizing transaction latencies. A single block may contain a mixture of transactions, including ones with Plutus scripts (smart contracts), native tokens, metadata, and simple ada transactions (payments). Similarly, a single transaction is currently limited to a maximum of 16KB. This ensures that a single block will always contain multiple transactions (at least 4, but generally many more), so improving the overall transaction throughput.

Block time budget is another property that is a fixed amount of time available to process all the transactions included in a single block. This is divided between the time that can be used for Plutus script execution and the time that is available for executing other transactions. This property ensures that transactions with Plutus scripts cannot monopolize the available time budget, and it will always be possible for the system to process simple payments in the same block that contains Plutus scripts. The total time budget for producing each block (including networking costs) is set to 1 second, with a budget of approximately 50 milliseconds available for Plutus script execution. In practice, this is a generous allowance – our benchmarking has shown that many real scripts will execute in 1 millisecond or less on a reference system.

The block time budget is currently set to 1 second. For security reasons, the Praos consensus protocol selects only a small fraction (one in 20) of the blocks that could potentially be added to the chain. For the current protocol parameters, the maximum transaction throughput (for simple transactions) is then approximately 11 transactions per second (TPS). Obviously, different transactions will vary in size and have different effective payloads. A single transaction could finalize an entire Catalyst voting round, for example, transferring millions of dollars of value.

As discussed above, each block is filled with a number of transactions that have been submitted by end users from wallets, the command-line interface (CLI), etc. These transactions are kept in a temporary in-memory holding area (the mempool) until they are ready to be processed and included in a block. Pending transactions are removed from the mempool as a block is minted, and new transactions can then be added to the mempool. By using a fixed-size mempool, we avoid the possibility of nodes being overloaded during high-demand periods, but this means that it may be necessary for a wallet or application to re-submit transactions. The mempool size is currently set to 128 KB: twice the current block size. This has been chosen based on queuing models.

Stretching the network

Ouroboros is designed to handle a large volume of data as well as transactions and scripts of different complexity and size. At present, and with current parameters, the Cardano network is utilizing on average only around 25% of its capacity. Of course, the most efficient scenario is that Cardano runs at or near 100% of its capacity (the network is saturated). While many networking solutions would suffer under such conditions, both Ouroboros and the Cardano network stack have been designed to be fair and highly resilient even under heavy saturation. Benchmarking analysis shows that under 200% saturation, the overall performance is still resilient and there are no network failures. Even while stress testing under 44x, the total available network capacity also shows no failures (though some transactions may be slightly delayed). The network is designed to work this way, using backpressure to manage the overall system load. So while some individual users taking part in a large NFT drop may experience longer wait times for their transactions, for example, or may need to resubmit the occasional transaction from a large batch (or spread the drops over a longer time period), this does not mean that the network is ‘struggling’. It actually means the network is performing as intended. We call it ‘graceful degradation’ and you can read more about it in the network design paper.

Wallets

Wallets act on behalf of end-users to submit payments and other transactions to the blockchain, and to track the blockchain status. One of the key services that a wallet provides is to submit transactions on the user’s behalf, confirm that they have been accepted onto the blockchain, and retry them on their behalf if the submission has not succeeded. That is, the wallet should take into account the effects of backpressure in the network as it becomes saturated, as well as other network effects (temporary disconnection, possible chain forks, etc). Wallets may be either:

• Full-node wallets (as Daedalus), which use local computing and network resources to run a node that connects directly to the Cardano network.
• Light wallets: these, in contrast, use shared computing and networking resources to serve a number of end users.

During periods of high demand (e.g., an NFT sale), both types of wallets may need to retry transactions. Since they share resources among many users, light wallets may need to temporarily scale the available computing and networking resources (including replicating endpoints) to ensure that user demand can be met. This demand-scaling is similar to the requirements that are placed when a company releases a popular new product, for example. In contrast, full node wallets may be essentially unaffected. Transactions may be slightly delayed, but each wallet will have the dedicated resources that are needed to retry the submission, including its own network connections. Similar principles apply to DApp providers – where specific network endpoints are provided, the system resources should be scaled to meet the demand.

Process optimization

We naturally welcome the innovation (and the dialog) that we are currently seeing in the NFT community. To improve the user experience, it is necessary to optimize development procedures so that the process of NFT creation, for example, works well even when causing system saturation. Many NFT creators are using batch minting for greater efficiency, for example.

We would encourage creators to look at how they can continue to optimize their own efforts in order to minimize network congestion. We’d also encourage everyone to join the Discord discussions as part of our Creator community and we’re making our engineers available in order to find the best matching solution to a particular case.

As well as the flexibility afforded by parameter adjustments – which can be made within an epoch if required – in the medium and longer term, further options will come into play. Hydra allows multiple operations to be run in parallel, which grants enhanced scalability. Its state-channel solutions increase the system throughput, also reducing the demand for on-chain execution. However, while Hydra helps with multiple scalability use cases, it doesn’t specifically address NFT creation efficiency. As Cardano continues to mature and grow, we will continue to look at how we optimize the network and manage the network capacity. As I recently talked about in our October mid-month update, as the network starts running at a higher capacity, we’ll be able to tune those Cardano parameters as needed. For example, reduce the block time budget, optimize the size and execution time of Plutus scripts or lower their execution cost and improve throughput.

Join our Discord community today to find out more and to discuss all things Cardano with our dedicated community.

Thanks to Neil Davies and Olga Hryniuk for their additional contributions and support in writing this post.

Cardano’s development has been conceived as a journey involving five overlapping development themes, each of which is underpinned by a consensus protocol – Ouroboros. As Cardano evolves, the protocol must also change as fresh functionality and utility are brought onto the platform. Upgrades require gradual changes to the network protocol and in this article, we will explain how these protocol changes are implemented and what goes on behind the scenes to make this process smooth and straightforward.

Reducing complexity in protocol changes

In the crypto world, any fundamental change to the blockchain protocol is referred to as a hard fork. In most blockchains, a hard fork is a ‘traumatic’ event that causes a – hopefully short – break in block production. In contrast, Cardano handles hard forks automatically, without stopping block production. This gives a uniquely smooth upgrade process that allows new features to be introduced easily and evolve the platform’s capabilities.

Traditionally, when a hard fork event occurs, the current protocol stops operating. All block producers upgrade to a new version of the software that implements the new block production rules or other changes. Having done this, the chain history is erased and block production is restarted. This means that a hard-forked chain will be different from the previous version, which can raise concerns over the integrity of the blockchain, or even lead to splits in the chain.

With Cardano, we do things differently

The way that Cardano implements protocol changes is completely different from the way other blockchains handle hard forks. Our goal has always been to make these changes as seamless as possible. To enable a smooth transition, Cardano automatically preserves the history of previous blocks. This allows the protocol to be upgraded without radical interference to the chain. The previous state does not vanish. Rather, it is extended to include new capabilities. Instead of splitting into two different chains, Cardano combines the original blocks that comply with the current block production rules with new blocks that comply with the new block production rules.

We have christened the mechanism that does this the hard-fork combinator since it combines protocols without triggering interruptions or forcing a restart to Cardano. The Byron to Shelley transition used this technique for the first time. But the crucial point here is that Byron’s chain history did not disappear. Byron and Shelley chains appear ‘as one’, where the Shelley blocks extend the chain that was produced in the Byron era. Shifting from Byron’s Byzantine Fault Tolerance consensus protocol (OBFT) to Shelley’s Ouroboros Praos did not require block production to be stopped or all the nodes to update simultaneously. Instead, nodes could update independently.

As Cardano and Ouroboros evolve, the hard fork combinator approach ensures that Goguen, Basho, and Voltaire blocks will all be held in a single chain. Features will be added at each stage in successive hard forks. Some new features may not even need a hard fork (where the consensus protocol does not change).

The advent of token locking

Token locking is a feature in the next protocol update that we are now preparing to deploy on mainnet. Internally, we are calling this development stage Allegra (named after Lord Byron’s daughter). Alongside the integration of metadata on the network, this is the next significant upgrade for Goguen.

This represents a relatively small technical change to the consensus protocol, with a slight impact on the actual ledger. However, it is significant since it will prepare the platform for smart contracts and the creation of assets (in addition to ada) that run on Cardano. It also provides an important piece of Voltaire (governance) functionality, supporting a voting mechanism. Underlying this are system changes to ensure that we can continue to develop through future hard forks.

Token locking is a way of recording that a specific token is being used for some purpose. By token, we mean the items that are counted by the blockchain ledger. Until now, there has only been ada, but soon many other custom tokens will be able to use the Cardano platform. Locking, in this case, means ‘reserving’ a certain number of tokens for a specified period of time so they cannot be disposed of to gain a benefit (such as voting, or running a smart contract).

We can compare this with earning dividends from shares. A person who buys shares in a company might be rewarded with a dividend from the company’s profits. Let’s assume that this dividend is paid at the end of each calendar year and requires the shareholder to have held their shares for the entire year. If they were to sell some of their shares at the end of November, they would lose all the dividends for those shares for that year. They have entered a conditional contract with the share provider that gives them something of value (here, a dividend) in return for holding a specific token (here, a share) for a certain period (in this case, a full calendar year).

Enabling complex smart contracts

Token locking is essential to enable complex smart contracts, and to support certain conditions, for example, when making a purchase. Thus, when someone enters into a contractual agreement to sell a house, a promise is made by the vendor that this house won’t be sold to another person – only to the person who actually pays the money. So, the token can represent the house in this case, whereas the ‘promise’ will be the actual token locking. If the house is sold to a third party, the promise in the contract will have been broken and any penalties will be invoked. This precise functionality will become available to contract providers with the introduction of token locking, using ada coins as the tokens. The ada may still be delegated to a stake pool as usual.

Within the Voltaire mechanism – which will be first used with Project Catalyst Fund2 voting – those ada holders who wish to participate in the voting process will need to ‘lock’ some ada. This will represent their voting rights, according to the amount of ada that they lock. It will prove that individuals have a certain number of votes, and eliminate the possibility of any votes being counted more than once. An individual cannot allocate more votes than they hold, or vote on contradictory ideas, or duplicate the votes.

How is this implemented?

The introduction of token locking will happen behind the scenes. It will not affect the experience of ada holders because Daedalus and Yoroi wallets will automatically be updated without requiring any action from ada holders.

However, to implement the updated version of Ouroboros that will support token locking, all the nodes that run the network will have to ‘agree’ on it (that is, reach consensus). To achieve this, stake pool operators and exchanges that are running nodes will simply have to download the new version of the code and check its operation. IOHK’s development teams will support stake pool operators and monitor the network throughout this process to ensure that the transition goes smoothly.

Once token locking is running on the mainnet Cardano ledger, subsequent hard forks will introduce multi-asset and other smart contract capabilities. These will also be able to use token locking, opening up many new possibilities for Cardano users. In time, this will also lay the groundwork for creating non-fungible (unique) tokens on the Cardano blockchain.

IOHK’s innovative hard fork combinator has given Cardano a secure, smooth path to regular protocol updates – each bringing fresh value and utility to the network while minimizing disruption and risk. We’re in the final stages of quality testing and will start the testnet deployment process this month, with an expectation of moving to the mainnet around the middle of December. During 2021, there will be more upgrades using the combinator – multi-asset support is coming up – as the Cardano platform continues to fulfill its potential. Stay tuned for an exciting year.

Full decentralization lies at the heart of Cardano’s mission. While it is not the only goal that we're focused on, in many ways, it is a goal that will enable and accelerate almost every other. It is integral to where we want to go as a project.

It is also where the philosophical and technical grounding of the entire Cardano project meets its community, in very real and tangible ways. This is why we have done a lot of thinking on how to achieve decentralization effectively, safely, and with the health of the ecosystem front of mind.

Defining decentralization

Let’s start by explaining what we mean by decentralization. This is a word that is fraught with challenge, with several competing meanings prevalent in the blockchain community.

For us, decentralization is both a destination and a journey. Shelley represents the first steps toward a fully decentralized state; from the static, federated approach of Byron to a fully democratic environment where the community not only runs the network, but is empowered and encouraged to take decisions through an on-chain framework of governance and voting.

True decentralization lies at the confluence of three essential components, working together in unison.

• Networking - where geographically distributed agents are linked together to provide a secure and robust blockchain platform.
• Block production - where the work of building and maintaining the blockchain is distributed across the network to a collection of cooperating stake pools.
• Governance - where decisions about the blockchain protocol and the evolution of Cardano are taken collectively by the community of Cardano stakeholders.

Only when all these factors exist within a single environment can true decentralization be said to have been achieved successfully.

Key parameters that affect decentralization

Let's talk about d, maybe.

The d-parameter performs a pivotal role in controlling the decentralization of block production. Decentralization is a spectrum, of course, rather than an absolute. In simple terms, d controls ‘how’ decentralized the network is. For example, at one extreme, d=1 means that block production is fully centralized. In this state, IOG’s core nodes produce all the blocks. This was how Byron operated,

Conversely, once d=0, and decentralized governance is in place and on chain, ‘full’ decentralization will have been achieved. At this point, stake pool operators produce all the blocks (block production is 100% decentralized), the community makes all the decisions on future direction and development (governance is decentralized), and a healthy ecosystem of geographically distributed stake pools are connected into a coherent and effective network (the network is decentralized). We will have reached our decentralization goal.

The journey that d will take from 1 to 0 is a nuanced one that requires a careful balance between the action of the protocol and the reaction of the network and its community. Rather than declining instantly, d will go through a period of ‘constant decay’ where it is gradually decremented until it reaches 0. At this point Cardano will be fully decentralized. This gradual process will allow us to collect performance data and to monitor the state of the network as it progresses towards this all-important point. A parameter-driven approach will help provide the community with transparency and a level of predictability. Meanwhile, we’ll be monitoring the results carefully; there will always be socio-economic and market factors to consider once ‘in the wild’.

How will the d parameter change over time

The evolution from 1 to 0 is relatively simple:

When d=1, all blocks are produced by IOG core nodes, running in Ouroboros Byzantine Fault Tolerance (OBFT) mode. No blocks are produced by stake pool operators (running in Ouroboros Praos mode). All rewards go to treasury.

When d=0, the reverse becomes true: every block will be produced by stake pools (running in Praos mode), and none by the IOG core nodes. All rewards go to stake pools, once the fixed treasury rate is taken.

In between these extremes, a fraction of the blocks will be produced by the core nodes, and a fraction by the stake pools. The precise amounts are determined by d. So when d reaches 0.7, for example, 70% of the blocks will be produced by the core nodes and 30% will be produced by stake pools. When d subsequently reaches 0.2, 20% of the blocks will be produced by the core nodes, and 80% by the stake pools.

It is important to note that regardless of the percentage of blocks that are produced by the stake pools, however, once d < 1, all the rewards will go to stake pools in line with the stake that they hold (after the fixed treasury percentage is taken), and none to the core nodes. This means that IOG has absolutely no incentive to keep the d parameter high. In fact, when d reaches zero, IOG will be able to save the costs of running the core nodes, which are not insubstantial.

Like many other ada holders, IO Global is currently running a number of stake pools on the mainnet. As the creator of the Cardano platform, IO Global naturally has a significant stake in its success from fiscal, fiduciary, and security aspects, and this success will be built on a large number of effective and decentralized pools. As a commercial entity, IO needs to generate revenue from its stake, while recognizing the part it needs to play within an ecosystem of stake pools, helping to grow and maintain the health of the network as we move towards full decentralization. In the medium term, we will follow a private/public/community delegation approach, similar to that we adopted on the ITN, spreading our stake across both IOG and community pools. In the short term, however, we are running IOG pools on the mainnet, establishing a number of our own pools that can take some of the load from our core nodes. Using our stake and technical expertise to secure and stabilise the network is an important element at first, but one that will become less important as the d parameter decreases. The road to decentralization will offer many opportunities for pools of all sizes to establish themselves and thrive along the way.

The key milestones of the d journey

d<1.0 (Move away from centralization)

The first milestone happened on August 13 at the boundary of epoch 210 and 211 when the d parameter first dropped below 1.0. At this point, IOG's core nodes started to share the block production of blocks with community stake pools. This marks the beginning of the road to full decentralization.

d=0.8 (Stake pools produce 20% of blocks)

At 0.8, more pools (double the number compared to d=0.9) will get the opportunity to create blocks and establish themselves. At this level, pools won’t suffer in the rankings as long as they create one of the allocated blocks and get rewards. This way, we believe we can start growing the block-minting proportion of the network, at low network risk.

d<0.8 (Stake pool performance taken into account)

The next major milestone will happen when d drops below 0.8. Below that level, each pool's performance will be taken into account when determining the rewards that it receives. Above that level, however, the pool’s performance is ignored. The reason for this is to avoid unfairness to pools when they are only expected to produce a few blocks.

d<0.5 (Stake Pools Produce the Majority of Blocks)

When d drops below 0.5, stake pools will produce the majority of blocks. The network will have reached a tipping point, where decentralization is inevitable.

Before taking this dramatic step, we will ensure that two critical features are in place: peer-to-peer (P2P) pool discovery and protocol changes to enable community voting. These will enable us to make the final push to full and true decentralization The recently announced Project Catalyst program was the first step in this, concurrent journey to full on-chain governance.

d=0 (Achieve Full Decentralization)

As soon as the parameter reaches 0, the IOG core nodes will be permanently switched off.

IOG will continue to run its own stake pools that will produce blocks in line with the stake they attract, just like any other pools. But these will no longer have any special role in maintaining the Cardano network. It will also, of course, delegate a substantial amount of its stake to community pools. Simultaneously, the voting mechanism will be enabled, and it will no longer be possible to increase d and ‘re-centralize’ Cardano.

At this point in time, we will have irrevocably entered a fully decentralized Cardano network. Network + block production + on-chain governance = decentralization.

Rate of constant decay

The progressive decrement of d is known as constant decay. The gradual decrease will give us the chance to monitor the effects of each decrement on the network and to make adjustments where necessary. As the parameter decreases, more stake pools will also be able to make blocks, since the number of blocks that are made by the pools will increase, and less stake will then be required for each block that is made.

The key factors driving this decrease will be:

• The resilience and reliability of the network as a whole.
• The number of effective block-producing pools.
• The amount of the total stake that has been delegated.

Here’s our current thinking on what implementation might look like:

We will then likely pause before dropping the parameter below 0.5 to ensure that the two key conditions described above are met:

• The implementation of the new Peer-to-Peer pool discovery mechanism has been released and is successfully in use;
• We have successfully transitioned the first hard fork in the Shelley era, which will introduce the basis for community voting on protocol parameters, and other important protocol changes

We will resume the countdown to d=0 at a similar rate, pausing again if necessary before finally transitioning to d=0 in March 2021.

Other factors that affect decentralization: Saturation threshold

A second parameter – k – is used to drive growth in the number of pools by encouraging delegators to spread their stake. By setting a cap on the amount of stake that earns rewards (the saturation threshold), new delegators are directed towards pools that have less stake. In ideal conditions, the network will stabilise towards the specific number of pools that have been targeted. In practice, we saw from the ITN that many more pools than this number were supported by the setting that we chose.

The k parameter was set to 150 at the Shelley hard fork. This setting was chosen to balance the need to support a significant number of stake pools from the start of the Shelley era against the possibility that only a small number of effective pools would be set up by the community. In due course, it will be increased to reflect the substantial number of pools that have emerged in the Cardano ecosystem since the hard fork. This will spread stake, and so block production, among more pools. The overall goal in choosing the setting of the parameter will be to maximise the number of sustainable pools that the network can support, so creating a balanced ecosystem. In order to achieve this, a careful balance is required between opening up the opportunity to run a block-creating pool to as many pools as want to run the system, against the raw economics of running a pool (from bare metal servers, to cloud services, to people’s time), taking into account the rewards that can be earned from the actively delegated stake. Changing this parameter will therefore be done with a degree of caution and balance so that we ensure the long term success of a fully decentralized Cardano network. We’re now looking carefully at early pool data and doing some further modelling before making the next move.

d and pool rewards

Two questions remain: What is the effect of d on the rewards that a pool can earn, and can this parameter ever be increased?

Regarding rewards, as long as a pool produces at least one block, the value of the parameter has absolutely no effect on the rewards that a pool will earn – only on the number of blocks that are distributed to the pools. So if a pool has exactly 1% of the stake, it will earn precisely 1% of the total rewards, provided that it maintains its expected performance.

Finally, while d could in theory be increased, there would need to be a truly compelling reason to do so (a major protocol issue, or fundamental network security, for example.) We would never envision actually doing this in practice. Why? Simply because we want to smoothly and gradually reduce the parameter to 0 in order to achieve our objective of true decentralization. We’ll be making this journey carefully but with determination step by step. If each step is taken thoughtfully and with confidence, you should not need to retrace them? As d becomes 0, the centralized IO servers will be finally switched off, and Cardano will become a model of decentralized blockchain that others aspire to be.

Conclusion

The decline of centralized entities coincides with Cardano's rise towards full and true decentralization. In the near future, the Cardano blockchain will be solely supported and operated by a strong community of stake pools whose best interest is the health and further development of the network.

This journey, which began with Shelley and the implementation of the d parameter, will take Cardano through a path of evolutionary stages in which the network will become progressively more and more decentralized, as d decays. The journey will only end when the blockchain enters a state of irrevocable decentralization, a moment in time that will see networking, block production, and governance operating in harmony within a single environment.

Today, we’re kicking off the ‘Friends & Family’ testnet, which will allow us to establish a robust network to test and iterate, before we roll it out to the wider community. We’ve gathered a small number of around 20 ‘pioneers’ to help us with this important initial work. By the time you probably read this, they’ll be briefed and we’ll have things underway.

In my last blog, I outlined how the Shelley experience will roll out within clearly defined phases. These first three phases will involve exploring and testing the new Shelley capabilities via a series of testnets. I thought it might be useful to offer a glimpse ahead to provide some additional context.

The rollout of the testnets will happen very much in parallel with our continued progress towards mainnet. So alongside the work on the Haskell Shelley testnet, the mainnet will be systematically upgraded to support the Shelley era protocol, that will enable staking, delegation and metadata.

Similarly, IOHK’s block-producing and public-facing relay nodes on the mainnet will be upgraded so that they are ready for Shelley, and the Blockchain Explorer, Daedalus Wallet, Wallet CLI and other user-facing software will be polished so that it can be used for mainnet.

Users will soon be able to go to the official Cardano websites or other providers such as Yoroi, to download a new wallet – currently in development – that will work with both Byron and Shelley era blocks. The Shelley-era Daedalus wallet will contain all the logic for staking and delegation that has been tested on the Incentivized Testnet, plus new features that are specific to the full Shelley protocol. Stakepool operators, exchanges and others will also be able to download Shelley-compatible nodes and to adapt their own software to support the new Shelley client API. However, during this period, the mainnet will still be running in Byron reboot mode with federated consensus governed by the OBFT (Ouroboros Byzantine Fault Tolerance) algorithm. Think of it as a time when forward compatibility is being integrated but not yet ‘switched on’.

The move to Shelley will be accomplished using the new hard fork combinator that has been developed by IOHK.The hard fork combinator allows a node to transition from one blockchain protocol to another. The Cardano node software that is running on the mainnet will gradually evolve so that it is able to deal with both Byron era and Shelley era blocks, and will be modified to include the hard fork combinator. When the time comes to move the mainnet from the Byron era to the Shelley era, IOHK will trigger a hard fork.

‘Switching on’ Shelley

This will activate the hard fork combinator within the nodes, and the nodes will then change from only producing Byron era blocks to only producing Shelley era blocks. After the hard fork, no new Byron era blocks will be recorded on the blockchain, and the nodes will be able to support distributed block production, staking and delegation. They will have seamlessly switched from the OBFT to the Ouroboros Praos consensus mechanism. We will have entered the Shelley era on the mainnet.

Distributed stake pools and Decentralization of Block Production

Central to Shelley is the idea of decentralization. IOHK believes that companies, systems, and platforms run by a single individual or central authority are more vulnerable and less fair. This is why it is crucial that we move block production to our supporters rather than keeping the power contained within our organizations.

The Cardano blockchain currently operates on a federated basis. Effectively, nodes ‘controlled’ by IOHK and EMURGO are responsible for block production, while Daedalus wallet users act as the nodes of the network. Shelley will mark the ‘beginning of the end’ of that era, as we move from Byron’s static federated system to an active, decentralized system.

At the moment, core nodes and relays are owned and operated by IOHK. The network propagates through relays into each individual wallet. Once the system decentralizes, nodes will be run by stake pool operators and networked with individual wallets. Once control of the system is transferred over, the community will be fully running the Cardano ecosystem.

Federated Block Production (Byron)

Following the hard fork, IOHK’s existing core nodes will initially produce all of the Shelley blocks, as in the Byron era. However, this will change over time, under the control of the built-in d (decentralization) parameter. This parameter can be considered as a control valve that allows increasing amounts of decentralization.

In the decentralization phase, the federated system will still produce a (steadily decreasing) portion of the blocks. As this happens, stake pools will begin registering, operating, and producing blocks and will start to earn rewards in proportion to the stake that is delegated to them. As time passes, more blocks will be made by stake pools and fewer will be made by the core consensus nodes. The balance between the two will be controlled by the d parameter.

Distributed Block Production (Shelley and Beyond)

We will use metrics like the amount of ada that has been staked to determine how quickly to change the d parameter and so to decentralize the network. Once the network has fully decentralized, the stake pools will completely take over block production. At that point, we will then be able to shut down the core consensus nodes and disable the d parameter. This is the first step towards the full decentralization of Cardano. We will return to that in future blog posts, when we discuss some of the exciting developments that the Shelley mainnet will enable.

The road towards Shelley has been long but creating a global financial and social operating system takes time, scientific rigor, and the support of an informed, passionate community. As always, we thank you for your support and encourage you to follow our official channels closely as the Haskell Shelley testnet and subsequent phases roll out.

Following the successful Byron reboot of Cardano, we are beginning our phased transition to the Shelley mainnet. This means moving from a static, federated system to a dynamic, decentralized Cardano blockchain.

The process begins with a series of Haskell Shelley testnets, culminating in the Shelley upgrade hybrid phase.

The Haskell Shelley testnets will be a different experience from the previous Incentivized Testnet (ITN) for both stake pool operators and general users/ada holders. This is because the ITN and the Haskell testnets have been created with different goals in mind.

The ITN was designed to give stake pool operators experience in building their critical infrastructure, while allowing IOHK’s engineers to test the new incentive mechanisms with real ada, delegated by actual ada holders. The Haskell Shelley testnet is about ensuring that the Shelley mainnet is calibrated to be a best-in-class experience from day one. Unlike the ITN, the Haskell Shelley testnet will not involve ‘regular’ ada holders: the testnet will not be incentivized. Each phase is intended to run for a much shorter period – weeks rather than months. We will, of course, be testing out the operation of the wallet, explorer, and so on, but using a faucet distributing test ada that doesn’t offer rewards. Ada holders will be able to try Daedalus and the explorer on the public testnet and provide feedback, but without using real ada.

The Shelley experience will roll out within clearly defined phases. The first three phases will involve exploring and testing the new Shelley capabilities and moving to a situation where we are ready for full Shelley mainnet deployment.

Phase 1: Pioneers and the ‘Friends & Family’ phase

The rollout will begin with an invitation-only ‘friends and family’ testnet. During this phase, IOHK will first spin up and run a Shelley-only test network internally. We will then invite about 20 trusted stake pool operators – we’re calling them ‘pioneers’ – to join this (initially closed) network. These operators will comprise a small group who have demonstrated a high level of technical skill and community contribution during the ITN.

These pioneers will blaze the trail for others to follow as we head to full Shelley deployment on the Cardano mainnet. In this important first phase, we’ll be asking them to perform specific functionality tests to capture their valuable feedback while exploring the capabilities of the Haskell Shelley platform. We expect to invite more pioneers to join us – a few at a time – as we add features and prove the reliability of the testnet.

In this ‘closed alpha’ testing phase, IOHK will focus on tuning system parameters such as the saturation threshold, network resilience, and decentralization. Furthermore, IOHK’s engineers will see the Ouroboros Praos consensus mechanism working outside of simulation. The pioneer phase will give IOHK’s engineers the opportunity to address any issues in a controlled environment, with feedback and support from stake pool operators, before moving to the next phase. The findings will be communicated to the Cardano community and opportunities will be taken to learn about and improve the Shelley system.

This phase will also be all about producing high-quality technical documentation and support. The pioneers (supported by the community as a whole) will help us produce documentation that will make it easy to set up and run stakepools, and give our technical support team an understanding of the issues that our users will face.

Phase 2: Opening up the testnet – the public phase

The community response to the ITN was incredible, and we are blessed with having a wealth of skilled stake pool operators in the community. We’ll keep everyone informed through every step of the process and – as ever – our repos will be fully open. But for purely practical reasons, we’ll be working 1-2-1 with just a small group of around 20 operators at first. But our goal is to open things up as soon as we can, with full public access in the next phase.

This will allow all the stake pool operators who participated in the ITN to redeploy their previously constructed infrastructure, and to tune their stake pool to the new Haskell settings. This testnet will run as closely as possible to mainnet conditions, including mixing Byron and Shelley era blocks.

During each evolution in the transition to Shelley, IOHK is placing an emphasis on community training and collaboration. Decentralization of knowledge is just as important as decentralization of the platform. Pioneer participants in the alpha testnet will provide crucial support in advising the remaining stake pool operators on configuration and use of the Shelley system. And as operators acclimatize, we’ll also be asking them to support and bring new operators on board.

Phase 3: The balance check

The third and final phase prior to mainnet deployment is the balance check. This will bring together the Byron and ITN transaction histories, and prepare the mainnet for the Shelley era. At this point, the ITN rewards and mainnet balances will be consolidated. After this point, it will no longer be possible to earn rewards on the ITN. However, users will be able to check their rewards and confirm them in mainnet wallets. We’ll share full details of what ada holders need to do to reclaim their ITN rewards a little nearer the time. The balance check phase will last for only a couple of weeks before we start moving towards decentralized stake pools and the Shelley era.

How we will select the pioneers

We are selecting the pioneer group based on a number of criteria, devised in collaboration with the team at the Cardano Foundation. Pool operators must have a deep knowledge of running stake pools on the ITN, as well as competency working with Linux, and come from a range of backgrounds and geographical locations. Some will be working with cloud solutions providers to run their pool, others with their own hardware – we’ll have a mix. By selecting pioneers from different geographical regions, we will be able to ensure a global reach, and test out our new network implementation.

Pioneers will be expected to commit a set number of hours per week to supporting the rollout program, give direct feedback and provide advice to the community and mentor others at subsequent phases. Bringing others on board and supporting them along the way will be a crucial part of the role. To be clear, as ever, all our repos will be open so we encourage everyone to get involved. As always, IOHK’s developers value input from every member of the Cardano community. Anyone who wishes to is encouraged to spin up their own nodes. If they are skilled developers they can also recommend enhancements to the Shelley Haskell code base because all the information will be published through GitHub.

We’ll be looking to expand the network rapidly with more pools as soon as this earliest testing phase delivers the results we want.

Ensuring an easier start for everyone

The Haskell Shelley code base has been developed with formal methods and the high assurance Haskell programming language. So while we anticipate that some minor elements will need addressing, we believe that the initial experience should be free of any major issues. This is the approach that we have used for the Byron reboot, with great success, and we will be building on the code base that we have developed there. The approach will deliver even greater benefits for Shelley and beyond, by allowing us to deploy software much more quickly than in the past, with new features subject to rigorous and careful checks even before coding has been completed.

Our goal is to provide a plug-and-play solution to get stake pool operators up and running. This means they should be able to pick up a pre-prepared docker image or AWS instance, for example, and their stake pool will be launched. We will, of course, also provide standalone binaries and source code for those with more experience, or who have specific configuration requirements.

We’re now in the final stages of preparation and things are heating up (you may have recently seen a tweet that the new node has produced its first block). With that successful first step completed, we’ll be sharing dates and more details very soon. We’ll also be publishing further blogs outlining the other key steps and milestones in the process. Keep an eye out for those and meanwhile stay tuned to IOHK’s social channels. We’ll be sure to let you know as we start rolling things out.