ČeskyThe Cardano Protocol is well prepared for the Future
We usually know well what has happened in the past. We can just assume what is going to happen in the future and still, we can be sure that we will be surprised by the development of events. A decentralized protocol must be designed in a way that it will be possible to respond to all expected or even unexpected events in the future.
The future is unpredictable.
Security and decentralization are not static properties
Security and decentralization are the most important properties of every cryptocurrency. These properties exist in the digital world. To be more precise, developers of a protocol try to design the protocol and then they implement the properties into the source code. The part of the design and implementation is an incentive model and native coin issuance. In other words, the protocol is a set of rules and algorithms that programmers have implemented based on the design hoping that the protocol will survive all attacks and will be sustainable in the long term. A decentralized protocol relies on the physical world. There are a lot of variables that cannot be assumed in advance. People have to be willing to maintain the protocol and will try to maximize their profit. They will study every detail of the protocol and try to come up with an improvement that would give them an advantage over others. Decentralization and security are not properties which quality would remain the same over time. The opposite is true. Both properties will dynamically change over time and the key to success is to keep the quality of the properties on a high level.
A network protocol is not only about security and decentralization. These two properties are not sufficient to attract people and satisfy their needs. There are other important properties like scalability, settlement time, transaction cost, and many others. The team must consider all properties and design the protocol in a way that all properties will be balanced. It makes no sense to create a super-secure protocol when it would process only a few transactions per second and cost would reach a few dollars. Security is a mandatory property but the real usability suffers in this example. To provide another example, it also makes no sense to create a super-fast protocol that would process hundreds of transactions per second for free if there would be only a few nodes responsible for the validation of blocks. The usability is high but decentralization is low. There is no guide on how to create the best protocol in the world and how the properties should be balanced. The protocol should be designed for a certain purpose and should be suitable for it. Thus, we need different properties for different purposes. It makes no sense to create a super-universal protocol for everything. It is often the case in IT that if one property is highly preferred then the quality of other properties can be lower. In addition, requirements for the protocol can change over time. It is fine that a team pursues the quality of some properties at the beginning but it can show up that people will require some other properties in the future. Moreover, competitors can appear and people might start using other protocols. For example, if scalability is needed for the adoption and usability of a protocol and the security has extra quality then it makes sense to consider decreasing security if it can help scalability.
Should a team prefer security over decentralization or vice versa? Where are borders of security and decentralization and how to measure the quality of them? There are no clear and simple answers. However, both properties should have a high quality and the team should consider changing the protocol if one property suffers due to the extreme quality of the other one. For example, if a protocol is extremely secure but the decentralization is bad then the team should strive to increase decentralization even if it would mean that security will be decreased. As we said, however, it might not be true in all cases. At the current stage of cryptocurrency adoption, we do not exactly know what people want, which properties they prefer, and what could increase the adoption. People usually care about properties that directly influence user experience. They see the speed of transactions, settlement time, and their cost. Security and decentralization are considered as implicit properties and the majority of users do not think much about them. To increase adoption the cryptocurrencies needs to also improve properties related to user experience. The current financial services are neither decentralized nor secure but they are very user friendly. It is probably naive to think that we can build a slow, expensive, and non-scalable protocol and people will start using it instead of the current services just because of properties to which they do not understand well anyway. It can be fine for minorities and it is what we can observe nowadays in the crypto space. After more than 10 years of cryptocurrency existence, we have not reached even 1% of adoption. It basically means that usability is not attractive enough for people and cryptocurrencies are not able to compete with the traditional financial system yet.
It is a very difficult task for teams to build protocols that will have a high level of usability and, at the same time, keep security and decentralization on a high standard. There are so many external conditions and the environment is so dynamic and unstable that the quality of security and decentralization will evolve and change over time. Team members together with users will have to guard security and decentralization. The team will have to consider changing the protocol appropriately when it becomes to be evident that some key properties degraded. Governance of decentralized protocols is still in infancy and we do not know how to deal with it. Teams usually do not know how to communicate with users and how to deal with feedback. How to communicate the opinions of teams towards users is not also clear. For example, users might want to improve decentralization and scalability. Who should be contacted and where and by whom the topic is discussed? If a team decides not to change the protocol as users wish since they know that it could threaten security then how should the team communicate that to users? Finally, who will give the mandate to a team? There are a lot of unanswered questions and the topic is more complex than you might think.
The future is unpredictable but the protocol can be prepared for changes
We believe that you now understand that the conditions in the physical world evolve and change every day. It can happen that something unexpected will happen and the protocol will have no pre-programmed reaction to it. As a result, security or decentralization, or even both properties, might degrade noticeably. If it happened then there are a few options on how to respond. The change in the physical world can be so fundamental or significant that it is necessary to redesign the protocol and recreate some parts of the consensus, change the incentive model, or come up with some major innovation. It could take a lot of time and effort. There might occur disputes in the community and the change can be expensive. Anyway, it is not a good approach to ignore the unsatisfying state since people might stop using the protocol and there are a lot of competitors waiting for their chance. The team must not hesitate. It must react appropriately and fix the issue.
The Cardano protocol has an advantage that other protocols usually do not have. At least as far as we know. It took a lot of time to design and develop the protocol but thanks to the smart approach of the IOHK team the properties of the protocol can be configured before the launch of the Shelley main-net. There are 20 parameters in the protocol that can be used to configure the quality of properties. If it is needed to change the quality of properties in the future then it will be quite easy to reconfigure the parameters within a new version of the client. It is a complex task to decide how to configure the protocol and it is expected that changes will be needed. There are many good reasons for having the possibility to change the quality of properties over time.
Most parameters have a rather technical character and they might influence each other. Parameters influence security, decentralization, performance, sustainability, stability, reward fairness, and many other things. As we have explained above, it is difficult to predict the future and prepare the protocol for all possible variants. The protocol relies on people, mainly on the behavior of pool operators and stake-holders. In the beginning, it can be expected that there will be fewer pool operators and stake-holders. Right after the launch of the protocol, security is the most important property that should be preferred and decentralization will be lower. Cardano is a decentralized network and decentralization is the core property about which the team and people care the most. It is not to say that security is less important. Both properties have to have high quality.
The ability to configure the protocol allows the team to prefer the security a bit more and as time progresses the decentralization can be more supported. It makes sense. People can be more interested in the creation of a pool, ADA coins will be more distributed and there will be more stake-holders. It makes sense to support the existence of more pools in the ecosystem. The increase of decentralization also increases security. For example, the protocol could be configured in a way that it prefers the existence of only 20 pools and their operators would need to have a big pledge. In this case, probably only whales would have the chance to operate pools since they can afford to buy a higher number of ADA coins. The protocol would be very secure since whales would act in their best interest to keep the value of ADA coins. The level of their skin in the game would be quite big. However, they would have big decision power and the protocol would not be considered as much decentralized. The Cardano protocol allows changing the rules in a way that decentralization will be increased once certain parameters are tuned. Thus, the team is able to maintain the protocol and balance the quality of properties as it will be needed in the future.
It is not naturally smart to change these parameters too often since it would negatively affect the stability of the network. The frequency should be rather years than months and it should be a response to the future’s needs and user’s requirements. Different players in the ecosystem will prefer a different setting. For example, pool operators could be more profitable if there would only a few of them but it is unhealthy for the level of decentralization. Stake-holders and users always prefer higher decentralization. Pool operators should be economically motivated to act honestly so pledge should not be too low. It is better to have a hundred pools with a reasonable pledge than thousands of pools with a very low pledge. Do not forget other properties. For example, the first option is definitely a better one from the point of performance and also security. Is it fair not to allow everybody to create their own pool? How large a pledge is actually fair? Nobody knows the correct answer but luckily we know properties that we need to keep balanced. Security, fairness, performance, stability, and other properties should be taken into account always when decentralization is considered.
The ability to quickly respond to the majority of eventualities is a strength that lacks in many other protocols. It can usually be quite simple to tweak an incentive and economic model. It can be a challenge to increase decentralization or to decrease security in order to support decentralization. Rules of many protocols do not allow quick and easy tweaking of properties on the source code level. The advantage of Ouroboros PoS is the ownership of the monetary system that is at the same time the precious resource that is used for the network consensus. The amount of ADA coins is capped and thus the system has fixed borders. In comparison with PoW networks, in PoS networks it is easier to tweak security and decentralization. In the PoW system, there is no upper limit for the electricity and thus the security of the network can grow even in the case when decentralization starts to suffer. It would be smart to decrease security if it could help to increase decentralization and balance the properties. Extremes are never a good thing. If there are only 10 big pools and a few small pools have hard times and struggle to be competitive then it is time to tweak the protocol and increase decentralization.
It should be stressed out that tweaking the protocol is not a centralized process where the team would remotely configure clients on operators’ nodes. Operators have to agree with changes and install a new version of the client. The team is probably the most competent subject to tweak the protocol but it should not be the team that solely decides about changes. Notice that we got back to the topic about decentralized governance of the protocol. Decentralized protocol governance is similar to the building of democracy. The majority should democratically decide about protocol properties but not all people are competent to make the decision. Decentralization requires a voting system and maybe delegates that would have a mandate to make a decision about complex topics.
How the Cardano protocol can be tweaked
It is out of the scope of the article to describe all parameters that can be used for tweaking the Ouroboros protocol. Nevertheless, we will describe the most important one that can be easily understood by everybody.
The k parameter determines the desired number of staking pools in the Cardano network. It does not set the maximum number of pools that can be created. The network will be always open and everybody can freely join or leave the network. The k parameter sets economical incentives in a way that the protocol encourages the existence of a given number of pools with equal size. The size of a pool is determined by the number of ADA coins that form the pool’s stake. There is a certain point of a pool size that is called saturation. Once a pool gets saturated it makes no sense to become bigger since it will not increase the reward that is provided by the protocol. When a pool is saturated then the pool operator is not motivated to increase pledge and delegators are motivated to delegate coins to not saturated pools. The design motivation behind the k parameter is to distribute rewards optimally to everybody when the stake is delegated uniformly to the desired number of saturated pools. In other words, economic incentives lead to the creation of k pools so it can be said that the parameter influences the level of decentralization.
The k parameter will be initially set to 150 and it will be gradually increased to 250 in the next phases. It is expected that there will be 150 pools with a similar size and if that is the case then every pool will have similar chances to become a slot leader and produce blocks.
Notice that it is easy to support a higher level of decentralization just by increasing the k parameter. On the other hand, pool operators and also delegators will get lower rewards. It can be expected that the k parameter can be set to 1000 within a few months or years. The demand for creating a pool is high. It is possible to set the k parameter in a way that the creation of thousands of pools will be supported.
A pool stake consists of ADA coins that staked by the pool operator and all stakeholders that delegated ADA coins to the pool. A pledge is a term for the number of ADA coins that are staked by the pool operator. Another parameter we would like to describe in the article is a parameter. The a parameter is a pledge influence factor that directly influences the rewards for a pool. The protocol does not blindly calculate the rewards for the pools only by the pool stake but it can take into account the pledge and the pledge influence factor. Thus, the higher the a parameter is the higher influence has the size of the pledge to the rewards. The higher the pledge influence factor is the more is the protocol protected against the Sybil attack. The pledge influence factor is important for the security of the protocol. There is not defined the pledge minimum and pool operators can pledge any number of ADA coins they want. However, it is not desired to have thousands of pools where owners have no or low skin in the game. On the other hand, a big pledge is advantageous for big players that can afford to pledge a big amount of ADA coins and discriminative for people that are not able to pledge a higher number of ADA coins. To keep the opportunities equal for everybody the role of the pledge should be rather low or none. There is a clash of interests between security and fairness. It is desirable to prefer security more than fairness so the protocol rewards more the pools with a higher pledge. Thus, a pool with a higher pledge will always earn more than a competitive pool with a similar stake but with a lower pledge. The difference is influenced by the a parameter. Pool operators are motivated to use their ADA coins as a pledge for their personal pools. Operators with higher pledge can set higher operational costs and they will be still competitive in comparison with other operators with a lower operational cost and a lower pledge. In other words, a higher pledge can ensure a higher profit.
Notice that if the a parameter would be very low then it would do no matter whether the stake of a pool consists only from delegated coins or only from the pledge. The reward would be nearly the same. There could be two pools with the same stake but the difference would be in the interests of actors. If there was a pool without pledge then the pool operator would have no skin in the game and could attack the protocol without risking its own wealth. From the decentralization point of view, the best approach is to economically motivate the creation of such pools where operators must pledge part of the stake and delegators choose pools with a higher pledge since rewards will be higher. Thus both pool operators and delegators are actively participating in the security and decentralization of the protocol with their own wealth.
The IOHK team has made a lot of simulations and concluded that the a parameter, that can be set from 0 to infinity, will have an initial value set to 0,3.
To be clear, the protocol rewards pools for producing blocks. Delegators should be interested in the performance of pools. A pool will get a certain number of opportunities to become a slot leader and produce blocks. The number of opportunities is based on the size of the stake. If the pool succeeds in 100% of cases that it will get maximal reward per given epoch. A pool can have a large pledge and be close to the saturation point but it gets no rewards if it fails to produce blocks.
How can rewarding be tweaked?
The Cardano protocol rewards pool operators and delegators at the end of each epoch. The protocol has two sources of ADA income. The first source of income is the collection of all fees in a given epoch. In the epoch, more blocks can be produced. In each block, there are a lot of transactions and the fee has been paid for each of them. Fees will be collected also for deploying smart contracts. The second source of income is the network subsidy (monetary expansion). There is a special budget (reserve) that will be gradually consumed to support the network in the first years of existence. It is expected that the number of transactions will grow in time. The budget is needed to economically motivate pool operators from the beginning when there will not be so many transactions.
Diving into Protocol Consensus
Would you like to know more about network consensus details? Then you will probably enjoy the article. We will dive into details regarding transaction processing and making consensus in a distributed network. Read more
ADA coins from both sources are placed into a virtual pot. The number of ADA coins from the first resource is determined by the number of processed transactions and deployed smart contracts. The subsidy budget is consumed gradually and the speed of consumption is determined by the ρ parameter. The ρ parameter is a fixed percentage determining how many ADA coins are taken from the budget in each epoch. Thus, the number of ADA coins in the budget will be gradually decreasing. The initial value of the ρ parameter will be initially set to 0,22%. It is expected that it will take 4 to 5 years to consume half of the budget. Thus, it can be considered as a kind of Bitcoin halving. The difference is that in the case of the Cardano protocol it is a gradual and smooth process that is predictable. There is no sharp decline in rewarding every 4 years. The budget is gradually depleted at the same speed. Notice that the budget will never be completely depleted in the foreseeable future. It will be halved every 4 to 5 years if the value of the parameter is kept the same.
Once both sources are placed in the virtual pot at the end of the epoch the protocol does two things. Firstly, a part of the ADA coins in the virtual pot is sent into the project’s treasury. The part is determined by the parameter τ and it will be initially set to 5%. With this setting, there will be at least 380,000,000 ADA coins in the treasury after 5 years. Secondly, the rest of the virtual pot, which is 95%, is used by the protocol to reward all pool operators and delegators.
Searching the right value for the ρ parameter is again a trade-off. A higher percentage would mean that stake-holders will get higher rewards and the project’s treasury will be filled faster. On the other hand, the budget would get depleted faster. It is smart to think in a long perspective and have sufficient ADA coins in the budget after 10 years. Nobody can predict the future and know how many transactions will be processed after 2, 3, or 5 years from the launch of the main-net. There is a chance to increase the ρ parameter if it is needed to motivate stake-holders more or decrease it in the case that there will be a lot of transactions processed every day after 5 years.
Summary
A lot of protocols have been developed in a rush and now it can be difficult to change some parts of it. It can be considered as technological debt. In the case of decentralized projects, changing is always a challenge. In some cases, it can be even impossible. The Cardano protocol has been developed for more than 5 years and is well prepared for the future. It is likely that it will be needed to change something in the future for many unpredictable reasons. Cardano is ready for it and the team will not need to spend a lot of time with troubles with security or decentralization. Thus, it can focus on further development and creating new features that increase usability. Security and decentralization will always be the main topic and the team will need to spend some time with it. However, it is possible to promptly react to some unexpected event and buy some time for considering a more complex fix. The IOHK team did a great job and we believe that Cardano protocol can serve us for decades without significant troubles with security or decentralization.
Links:
Read other relevant articles on the IOHK blog: https://iohk.io/en/blog/posts/2020/06/25/iterating-for-growth-with-iohk/
https://iohk.io/en/blog/posts/2018/10/29/preventing-sybil-attacks/
Read the great article and calculations from Umed Saidov: https://www.reddit.com/r/cardano/comments/gfed1l/cardano_mainnet_pledge_influence_factor_analysis/
The great video about the topic made by The Cardano Community Podcast: https://www.youtube.com/watch?v=Mq7qoMDVttc
The great and very detailed explanation by Sebastien Guillemot (Emurgo): https://twitter.com/SebastienGllmt/status/1259677222404677632