Plutus fee estimator: find out the cost of transacting on Cardano
Our new fee estimator – released today – will help developers estimate the cost of smart contract scripts for maximum efficiency and minimum cost
21 January 2022 6 mins read
The ‘Alonzo’ smart contract upgrade deployed to the Cardano mainnet in September 2021 turned Cardano into a functional platform for the development of decentralized applications (DApps) built in Plutus.
With the Cardano ecosystem steadily growing, a great number of DApps are being built and readied for launch on Cardano. Either in final testing, deployment, or active development, Cardano will soon host a variety of DApps covering DeFi offerings, NFT markets, wallets, exchanges, games, and more.
The deterministic design of the Cardano ledger allows developers to predict how much they will pay for contract execution and there’s no fee for contract failure. Deterministic transaction processing, low fees, and security – all of these are major benefits of transacting and building on Cardano. Here, we’ll take a closer look at Cardano pricing and introduce a new Plutus fee estimator developed to provide better clarity on the processing fees.
The benefits of building on Cardano
Many factors influence a blockchain's price competitiveness: functionality, quality, security, and, of course, liquidity.
The design principles underpinning the Cardano ledger ensure high performance while respecting rigorous security properties. Cardano uses an Extended Unspent Transaction Output (EUTXO) accounting model, which greatly contributes to its deterministic design. Determinism refers to the predictability of outcomes. This means that Cardano transactions and scripts can be validated locally (off-chain), so letting the user know if a transaction is valid before executing it on-chain and without paying any fees. Moreover, transaction fees are fixed and predictable. To compare, smart contract execution costs on Ethereum vary depending on the network load, with fees fluctuating from $5 to hundreds of dollars (see The ridiculously high cost of Gas on Ethereum). Moreover, even failed Ethereum transactions may also incur fees, creating additional uncertainty about pricing.
In contrast, on Cardano, users can calculate the potential fees for transaction processing in advance. Because the user knows in advance whether the transaction is valid or not, there is no need to pay for a transaction that will potentially fail. This saves wasting funds and eliminates on-chain failures. Cardano’s execution fee in ada is always stable as it depends on pre-set network protocol parameters rather than on varying network congestion factors, for example.
Cardano’s pricing model relies on demand over supply
Cardano’s approach to price setting mainly relies on market demand over actual supply. With smart contract support on Cardano, there is now more than one type of demand competing for the common supply. Thus, it is crucial to consider both relative and absolute pricing. One way to do this is to inspect the effects of smart contract pricing, non-fungible token (NFT) operations, etc., with respect to some common value – in our case, the consumption of Cardano’s processing power.
With Cardano, smart contract pricing model is based on a fixed cost, which relies on the pricing of the spent resources (UTXO size or computation/memory used when running).
Fees must be paid to fairly compensate for stake pool operation (SPO) work and for the resources used to validate network transactions. In addition, making sure that any particular way of using Cardano is not substantially cheaper than another helps mitigate whole classes of adversarial attacks (e.g. a classic DDoS attack).
Flexibility is also key and an important feature of the Cardano protocol as it provides the possibility to change its parameters and adapt to price fluctuations. For example, if ada significantly increases in value, protocol parameters can, if required, be adjusted to prevent the user from overpaying for smart contract execution.
Plutus fee estimator
The Plutus fee estimator tool has been developed by IOG for price benchmarking and comparison. Today we are making it available for developers or curious Cardano users on our public testnet site. The estimator uses information from real-world Plutus transactions to predict the fees that will be charged for a transaction. The estimator can be used to calculate fees for actual transactions (e.g. to determine the fees that will be charged if the network parameters change), and also to estimate fees for individual script transactions or complete DApps before or during development. It may also be useful to determine the effect of script changes or optimizations on fees.
The estimator uses the same fee calculation formula as the actual Cardano node. Given sufficiently accurate inputs, it can give an accurate idea of the required fee. By combining the costs from multiple transactions, a user can easily predict how much a whole DApp might cost. This will be valuable for developers, business analysts, etc. The estimator includes a number of examples based on real transactions that have been verified against actual fees.
Fee calculation requires three pieces of information:
- The total on-chain transaction size in bytes: a simple transaction, for example, is around 300 bytes, one with metadata is around 650 bytes, and Plutus scripts are typically 4,000-8,000 bytes (future optimizations will reduce this).
- The number of computational (CPU) steps that the script uses: each step represents 1 picosecond of execution time on a benchmark machine. Typical scripts should consume less than 1,000,000,000 CPU units (1 millisecond).
- The number of memory units that the script uses: this represents the number of bytes that the script allocates. Typical scripts should consume less than 1,000,000 memory units (1MB of memory allocation).
Let’s take a look at example Plutus scripts to understand their execution costs (Figure 1):
Figure 1. Estimated fees for script processing on Cardano
The estimator shows that sending a simple transaction would be as cheap as 0.17 ada, whereas the maximum possible cost for a single script would be 2.17 ada.
The calculation can be extended to DApp execution (see Figure 2). For example, a DApp using three transactions (one simple and two script transactions) might cost ~ 1.50 ada.
Figure 2. Estimated fees for DApp execution on Cardano
The final word
The Alonzo HFC event enabled Plutus script execution on the Cardano mainnet. This was really just the beginning of the journey for Cardano smart contracts. Now, with the launch of major smart contracts projects, we can begin the process of optimization and scaling. This includes the ongoing assessment of actual, real-world smart contract usage.
We need to balance the needs of the user and what is good for the network, speed versus correctness, and – as ever – striking that balance between security, scalability, and decentralization.
Future code/script optimizations and system performance improvements will help to refine the Cardano fees model over time. Together with our developer and stake pool operator communities, we will monitor the growth of smart contracts, optimize the Cardano node and the Plutus interpreter implementations, and make other adjustments to best support our user base in terms of fair and predictable transaction fees.
Check out the Plutus fee estimator on testnets.cardano.org and be sure – you can easily estimate the processing fee without losing your funds in case of transaction failure.
Cardano: robust, resilient – and flexible
With its modular, parameter-based approach, Cardano has been architected with true scalability in mind
21 October 2021 10 mins read
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.
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.
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 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.
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.
Goguen brings token locking to Cardano
We’re deploying the same process used for the Shelley update to deliver a smooth upgrade path to Goguen
2 December 2020 7 mins read
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.
The decline and fall of centralization
This week marks the first step in the road to the full decentralization of Cardano, as stake pools begin to take responsibility for block production. Here’s what the journey will look like.
14 August 2020 12 mins read
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.
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.
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.
From Byron to Shelley: part two, the journey to the mainnet
Continuing on to Shelley with the decentralization of block production
11 May 2020 5 mins read
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.