diff --git a/.docusaurus/docusaurus-plugin-content-docs/default/version-current-metadata-prop-751.json b/.docusaurus/docusaurus-plugin-content-docs/default/version-current-metadata-prop-751.json index 1c0282b9..e7867db5 100644 --- a/.docusaurus/docusaurus-plugin-content-docs/default/version-current-metadata-prop-751.json +++ b/.docusaurus/docusaurus-plugin-content-docs/default/version-current-metadata-prop-751.json @@ -189,8 +189,8 @@ { "type": "link", "label": "Design rationale", - "href": "/explore-cardano/cardano-design-rationale", - "docId": "explore-cardano/cardano-design-rationale", + "href": "/evolution/cardano-design-rationale", + "docId": "evolution/cardano-design-rationale", "unlisted": false }, { @@ -1944,4 +1944,4 @@ "sidebar": "tutorialSidebar" } } -} \ No newline at end of file +} diff --git a/.docusaurus/globalData.json b/.docusaurus/globalData.json index 3a878b9d..dd95f0cd 100644 --- a/.docusaurus/globalData.json +++ b/.docusaurus/globalData.json @@ -336,8 +336,8 @@ "sidebar": "tutorialSidebar" }, { - "id": "explore-cardano/cardano-design-rationale", - "path": "/explore-cardano/cardano-design-rationale", + "id": "evolution/cardano-design-rationale", + "path": "/evolution/cardano-design-rationale", "sidebar": "tutorialSidebar" }, { @@ -690,4 +690,4 @@ "breadcrumbs": true } } -} \ No newline at end of file +} diff --git a/.docusaurus/routes.js b/.docusaurus/routes.js index d4acd281..060f00c3 100644 --- a/.docusaurus/routes.js +++ b/.docusaurus/routes.js @@ -445,8 +445,8 @@ export default [ sidebar: "tutorialSidebar" }, { - path: '/explore-cardano/cardano-design-rationale', - component: ComponentCreator('/explore-cardano/cardano-design-rationale', '9ff'), + path: '/evolution/cardano-design-rationale', + component: ComponentCreator('/evolution/cardano-design-rationale', '9ff'), exact: true, sidebar: "tutorialSidebar" }, diff --git a/docs/02-new-to-cardano/02-what-is-a-cryptocurrency.mdx b/docs/02-new-to-cardano/02-what-is-a-cryptocurrency.mdx index 1a133580..6388a096 100644 --- a/docs/02-new-to-cardano/02-what-is-a-cryptocurrency.mdx +++ b/docs/02-new-to-cardano/02-what-is-a-cryptocurrency.mdx @@ -38,7 +38,12 @@ value (whether defined by the community, market state, or self-governed entity). A token can be fungible (interchangeable) or non-fungible (unique), and act as a payment unit, reward, trading asset, or information holder. -#### Related Topics +:::info + +Related topics: - [Cardano monetary policy](/explore-cardano/monetary-policy) -- [Learn about native tokens](/native-tokens/learn) +- [Learn about native tokens](/native-tokens/learn). + +::: + diff --git a/docs/02-new-to-cardano/03-why-use-cardano.mdx b/docs/02-new-to-cardano/03-why-use-cardano.mdx deleted file mode 100644 index 02bafd0b..00000000 --- a/docs/02-new-to-cardano/03-why-use-cardano.mdx +++ /dev/null @@ -1,169 +0,0 @@ ---- -title: Why use Cardano? -metaTitle: Why use Cardano? ---- - -[Cardano](https://cardano.org/) is an open source [proof-of-stake](/new-to-cardano/proof-of-stake) blockchain project that began in 2015 -to address existing blockchain challenges in the design and development of -cryptocurrencies. It aims to provide a more balanced and sustainable ecosystem -that better accounts for the needs of its users as well as other systems seeking -integration. - -The first generation of blockchains (like Bitcoin) offered decentralized ledgers -for secure cryptocurrency transfer. However, such blockchains did not provide a -functional environment for complex deal settlement and decentralized application -(DApp) development. As blockchain technology matured, the second generation -(like Ethereum) provided more enhanced solutions for writing and executing smart -contracts, application development, and the creation of different token types. -On the other hand, the second generation of blockchains often faces issues in -terms of scalability. - -Cardano is conceived as the third-generation blockchain as it combines the -properties of the prior generations and evolves to meet all the arising needs of -users. When comparing blockchain properties, many aspects should be considered. -Thus, the best solution must ensure the highest security, scalability -(transaction throughput, data scale, network bandwidth), and functionality -(besides transaction processing, the blockchain should provide all means for -business deal settlement). Moreover, it is important to ensure that blockchain -technology is constantly developing in terms of sustainability and is -interoperable with other blockchains and financial institutions. - -To address these needs, Cardano focuses on such core concepts as: - -- **Scalability** — ensures that the Cardano network is capable of processing an increasing - number of transactions as user demand grows. - Scalability also provides higher bandwidth capabilities to allow transactions - to carry a significant amount of supportive data that can be easily managed - within the network. For these needs, Cardano is implementing various - techniques (like data compression for instance) and introduces - [Hydra](https://iohk.io/en/research/library/papers/hydrafast-isomorphic-state-channels/), - which will enable multiple sidechain functionality. -- **Interoperability** — ensures the most multi-functional environment for - financial, business, or commercial operations by enabling users to interact - not only with one type of currency, but with multiple currencies across - various blockchains. Moreover, interoperability with centralized banking - entities is as important to grant legitimacy and convenience of use. Cardano - aims to support cross-chain transfers, multiple token types, and - commonly used smart contract languages. Read more about the concept of [partner chains](https://iohk.io/en/blog/posts/2023/11/03/partner-chains-are-coming-to-cardano/). -- **Sustainability** — designing a proof-of-stake blockchain means it is vital - to ensure that the system is self-sustainable. To drive growth and maturity in - a truly decentralized manner, Cardano is built to allow the community to - maintain its continuous development by participating, proposing, and - implementing system improvements. This is now being implemented through [CIP-1694](https://cips.cardano.org/cip/CIP-1694) on-chain governance mechanisms. - -## Cardano advantages - -- **Academic research** — formal methods, such as mathematical specifications, - property-based tests, and proofs, are the best way to deliver high assurance - software systems and give confidence to users for the management of digital - funds. Cardano has been built using formal methods to achieve strong - guarantees on the functional correctness of core components of the system. All - of the research and technical specifications that underpin Cardano are - publicly available, and all Cardano development activity is published online. -- **System design** — Cardano is written in Haskell, a secure functional - programming language that encourages building a system using pure functions, - which leads to a design where components are conveniently testable in - isolation. Advanced features of Haskell enable employing a - whole range of powerful methods for ensuring code correctness, such as - basing the implementation on formal and executable specifications, extensive - property-based testing, and running tests in simulation. -- **Security** — - [Ouroboros](https://iohk.io/en/blog/posts/2020/06/23/the-ouroboros-path-to-decentralization/) - (the Cardano proof-of-stake protocol) establishes rigorous security - guarantees; it was delivered with several peer-reviewed papers presented in - top-tier conferences and publications in the area of cybersecurity and - cryptography. -- **Energy efficiency** — Cardano is a proof-of-stake blockchain. In contrast to - proof-of-work blockchains, [Cardano requires much less energy](https://iohk.io/en/blog/posts/2021/08/17/why-they-re-calling-cardano-the-green-blockchain/) and computational - power. The Bitcoin network is secured through computers doing - ever-more-energy-intensive computations – proof of work – which is - unsustainable in the long term. Cambridge University has an online tool that - shows the [computers powering Bitcoin](https://cbeci.org/) already consume - more electricity than some countries, like [Switzerland](https://www.bfe.admin.ch/bfe/en/home/supply/statistics-and-geodata/energy-statistics/overall-energy-statistics.html) for example. -- **Seamless upgrades** — traditionally, blockchains upgrade using hard forks. - When conducting a hard fork, the current protocol would stop operating, new - rules and changes would be implemented, and the chain would restart – with its - previous history being erased. Cardano handles hard forks differently. Instead - of implementing radical changes, the Cardano - [hard fork combinator technology](https://iohk.io/en/blog/posts/2020/05/07/combinator-makes-easy-work-of-shelley-hard-fork/) - ensures a smooth transition to a new protocol while saving the history of the - previous blocks and not causing any disruptions for end users. -- **Decentralization** — Cardano is maintained by over 3,000 distributed stake - pools that are operated by the community. All blocks and transactions are validated by - network participants without any reliance on a centralized authority. -- **Functional environment for business use cases** — Cardano is establishing a - foundation for global, decentralized finance to develop a range of DApps that - can run using functional and domain-specific smart contracts, providing - multi-asset tokens for any needs. - -## Cardano development phases - -[Cardano’s development journey](https://roadmap.cardano.org/en/) has been split -into five main themes focusing on such core functionalities as: - -- Byron — foundation establishment -- Shelley — decentralization -- Goguen — smart contracts -- Basho — scalability -- Voltaire — governance - -Each theme is centered around a set of functionalities that are being delivered -across multiple code releases. While these development streams are delivered -sequentially, the work for each happens in parallel – with research, -prototyping, and development often in progress all at once across the different -stages. Let’s take a closer look at these development themes. - -**Byron** - -Byron set the foundation for Cardano development allowing users to buy and sell -ada on a proof-of-stake blockchain network. Initially, the Cardano ledger was -established as a federated network, where block production and transaction -validation were maintained by Input Output Global (the company that develops -Cardano technology) and [Emurgo](https://emurgo.io/) (the company that drives Cardano commercial -adoption) stake pools. Byron saw the delivery of [Daedalus](https://daedaluswallet.io/) and Yoroi wallets, and -also provided users with a Block Explorer ‒ a tool specifically designed for -browsing the blockchain. - -**Shelley** - -The Shelley development theme introduced a decentralized ledger creating a -completely new economic system, which drives the network’s growth and gradual -optimization. Shelley evolved from Byron’s federated network maintenance, with -more and more blocks being produced by the distributed stake pool operator -community. This theme focused on a number of critical steps that ensure enhanced -user experience in terms of stake pool operation, delegation preferences, and -incentives. As a proof-of-stake network, Cardano Shelley introduced the -Incentivized Testnet (ITN) which proved that the blockchain can be sustainable -in the long term by relying exclusively on community-managed pools. - -**Goguen** - -Goguen development focused on the establishment of a global, financial and -multi-functional system for decentralized application (DApp) building, smart -contract support, and custom token issuance. Goguen is a key building block to -establish a versatile platform to build solutions around such application -domains as supply chain, track and trace, finance, medical records, identity -voting, property registration, P2P payments, and many others. - -**Basho** - -Basho focuses on Cardano’s optimization in terms of improving the scalability -and interoperability of the network. Whereas other development stages focus on -decentralization and new functionality, Basho is about improving the underlying -performance of the Cardano network to better support growth and adoption for -applications with high transaction volume. - -**Voltaire** - -Decentralized governance and decision making lie at the heart of Voltaire -granting the Cardano community the ability to vote on network development -updates, technical improvements, and project funding. For the Cardano network to -become more decentralized, it requires not only the distributed infrastructure -introduced during Shelley but also the capacity to be maintained and improved -over time in a decentralized way. - -### Related topics: -- [Understanding Cardano](https://www.youtube.com/watch?v=Ja9D0kpksxw) (Cardano whiteboard by Charles Hoskinson) -- [Cardano design rationale](/explore-cardano/cardano-design-rationale) -- [Detailed Cardano roadmap](https://roadmap.cardano.org/en/) -- [Development status updates](https://www.essentialcardano.io/development-update) diff --git a/docs/02-new-to-cardano/08-types-of-wallets.mdx b/docs/02-new-to-cardano/08-types-of-wallets.mdx index d70fa35a..312ffd6c 100644 --- a/docs/02-new-to-cardano/08-types-of-wallets.mdx +++ b/docs/02-new-to-cardano/08-types-of-wallets.mdx @@ -105,6 +105,7 @@ See **Other options** +- [Lace](https://www.lace.io/) - [Nami](https://namiwallet.io/) - [Eternl](https://eternl.io/app/mainnet/welcome) - [GeroWallet](https://gerowallet.io/) diff --git a/docs/02-new-to-cardano/09-how-to-delegate.mdx b/docs/02-new-to-cardano/09-how-to-delegate.mdx index a31712cf..0c79f0bb 100644 --- a/docs/02-new-to-cardano/09-how-to-delegate.mdx +++ b/docs/02-new-to-cardano/09-how-to-delegate.mdx @@ -20,9 +20,10 @@ Note that you can spend your ada at any time, regardless of how you delegated it ::: -Ada holders can delegate their stake using Daedalus, Yoroi, or other ecosystem wallets. Here are +Ada holders can delegate their stake using different ecosystem wallets that support this functionality. Here are some useful articles to review: +- [How to stake your ada](https://www.essentialcardano.io/infographic/how-to-stake-your-ada) - [How to choose a stake pool](https://iohk.zendesk.com/hc/en-us/articles/900002174303-How-to-choose-a-stake-pool) - [How safe is it to delegate to a stake pool?](https://iohk.zendesk.com/hc/en-us/articles/900002046123-How-safe-is-it-to-delegate-to-a-stake-pool-) - [How to delegate to a stake pool](https://iohk.zendesk.com/hc/en-us/articles/900005718683-How-to-Delegate-to-a-stake-pool) diff --git a/docs/02-new-to-cardano/10-what-is-a-smart-contract.mdx b/docs/02-new-to-cardano/10-what-is-a-smart-contract.mdx index 03f8dd70..cf2119fd 100644 --- a/docs/02-new-to-cardano/10-what-is-a-smart-contract.mdx +++ b/docs/02-new-to-cardano/10-what-is-a-smart-contract.mdx @@ -33,10 +33,12 @@ contracts using different programming languages. Here are some examples: Discover more ecosystem [builder tools here.](https://developers.cardano.org/tools) -::: - -## Further reading and related topics +Further reading and related topics: - [Developer Portal - smart contracts overview](https://developers.cardano.org/docs/smart-contracts/) - [A list of community-built developer tools on Cardano](https://www.essentialcardano.io/article/a-list-of-community-built-developer-tools-on-cardano) +::: + + + diff --git a/docs/02-new-to-cardano/index.mdx b/docs/02-new-to-cardano/index.mdx index 52e0fb80..2a3398db 100644 --- a/docs/02-new-to-cardano/index.mdx +++ b/docs/02-new-to-cardano/index.mdx @@ -9,8 +9,5 @@ with blockchain and [Cardano](https://cardano.org/) in particular. In this section, we start our journey with basic concepts such as the notion of blockchain, understanding consensus, and what is a -cryptocurrency. You will also find out how Cardano differs from other existing -solutions, learn how to track blockchain activities, and understand why smart -contracts matter. If you are new to Cardano, you will also find out information -about various crypto wallets, their applicability with Cardano’s native currency -ada, and how to purchase crypto. +cryptocurrency. You will also find out about various types of wallets and tracking tools, and understand why smart +contracts matter. diff --git a/docs/03-learn/02-cardano-node.mdx b/docs/03-learn/02-cardano-node.mdx index 5cb07195..ad495411 100644 --- a/docs/03-learn/02-cardano-node.mdx +++ b/docs/03-learn/02-cardano-node.mdx @@ -25,7 +25,7 @@ combined stake of various stakeholders in a single entity. The goal of blockchain technology is the production of an independently-verifiable and cryptographically-linked chain of records (blocks). A network of block producers works to collectively advance the blockchain. A -[consensus](https://docs.cardano.org/learn/consensus-explained) protocol +[consensus](/learn/consensus-explained) protocol provides transparency and decides which candidate blocks should be used to extend the chain. @@ -33,7 +33,7 @@ Submitted valid transactions might be included in any new block. A block is cryptographically signed by its producer and linked to the previous block in the chain. This makes it impossible to delete transactions from a block, alter the order of the blocks, remove a block from the chain (if it already has a number -of other blocks following it), or to insert a new block into the chain without +of other blocks following it), or insert a new block into the chain without alerting all the network participants. This ensures the integrity and transparency of the blockchain expansion. @@ -56,7 +56,7 @@ aggregated stake of their owners and other stakeholders, also known as _delegators_. Slot leaders are randomly elected from among the stake pools. The more stake a pool controls, the greater the chance it has of being elected as a slot leader to produce a new block that is accepted into the blockchain. This is -the basic concept of proof of stake (PoS). To maintain a level playing field, +the basic concept of [proof of stake (PoS)](/new-to-cardano/proof-of-stake). To maintain a level playing field, and prevent a situation where a small number of very large pools control the majority of stake, Cardano has an incentive system that discourages delegation to pools that already control a large portion of the total stake. @@ -69,14 +69,12 @@ the transaction’s parameters are met. Assuming that the transaction meets all these requirements, the slot leader will record it as a part of a new block, which will then be connected to other blocks in the chain. -### Cardano node course +:::info -The IOG Academy provides a series of -[video tutorials](https://www.youtube.com/playlist?list=PLNEK_Ejlx3x2ut-Pq-hi0NFVsgKB3EddR) -on YouTube that describe a variety of topics from installing the node to using -many of its features. +Related topics: + +- [About the Cardano network](/explore-cardano/cardano-network) + +::: -#### Related topics: -- [About the Cardano network](https://docs.cardano.org/explore-cardano/cardano-network/about-the-cardano-network) -- [Operating a stake pool](https://docs.cardano.org/operating-a-stake-pool/stake-pool-operations-101/) diff --git a/docs/03-learn/03-stake-pools.mdx b/docs/03-learn/03-stake-pools.mdx index 1c7b13bd..cd121810 100644 --- a/docs/03-learn/03-stake-pools.mdx +++ b/docs/03-learn/03-stake-pools.mdx @@ -3,15 +3,21 @@ title: Stake pools metaTitle: Stake pools --- -A stake pool is a reliable server node that focuses on ledger maintenance and holds the combined resources -the 'stake'- of various stakeholders in a single entity. Stake pools are responsible for processing transactions that will be placed in the ledger, as well as producing new blocks. Stake pools are at the core of [Ouroboros](https://iohk.io/en/blog/posts/2022/06/03/from-classic-to-chronos-the-implementations-of-ouroboros-explained/), Cardano's proof-of-stake protocol. +A stake pool is a reliable server node that focuses on ledger maintenance and holds the combined resources - the 'stake' - of various stakeholders in a single entity. Stake pools are responsible for processing transactions that will be placed in the ledger, as well as producing new blocks. Stake pools are at the core of [Ouroboros](https://iohk.io/en/blog/posts/2022/06/03/from-classic-to-chronos-the-implementations-of-ouroboros-explained/), Cardano's proof-of-stake protocol. -To be secure, Ouroboros requires a good number of stakeholders to be online and maintain sufficiently good network connectivity at any given time. This is why Ouroboros relies on stake pools, entities that are committed to run the protocol 24/7, on behalf of the contributing stakeholders that hold ada. The idea is that these resource holders can bring their resources (their stake) together and form a *pool*, where typically one holder is the operator of the pool and the rest are delegators. Typically, the stake pool operator (SPO) installs and runs software compatible with the platform (the server node), while delegators take a more passive role. They delegate their stake to the pool. +To be secure, Ouroboros requires a good number of stakeholders to be online and maintain sufficiently good network connectivity at any given time. This is why Ouroboros relies on stake pools, entities that are committed to running the protocol 24/7, on behalf of the contributing stakeholders that hold ada. The idea is that these resource holders can bring their resources (their stake) together and form a *pool*, where typically one holder is the operator of the pool and the rest are delegators. Typically, the stake pool operator (SPO) installs and runs software compatible with the platform (the server node), while delegators take a more passive role. They delegate their stake to the pool. -While Ouroboros is cheaper to run than a proof-of-work protocol, running Ouroboros still incurs some costs. Therefore, SPOs are rewarded for running the protocol in the form of incentives that come from the transaction fees and from inflation of the circulating ada supply. +While Ouroboros is cheaper to run than a proof-of-work protocol, running Ouroboros still incurs some costs. Therefore, SPOs are rewarded for running the protocol in the form of incentives that come from the transaction fees and inflation of the circulating ada supply. + +:::info + +Further reading: + +* [About stake pools, operators, and owners](/operating-a-stake-pool/about-stake-pools) + +::: -**Further reading**: -* [About stake pools, operators, and owners](https://docs.cardano.org/operating-a-stake-pool/about-stake-pools/) diff --git a/docs/03-learn/04-delegation.mdx b/docs/03-learn/04-delegation.mdx index 3534d2d2..5845bb63 100644 --- a/docs/03-learn/04-delegation.mdx +++ b/docs/03-learn/04-delegation.mdx @@ -15,26 +15,31 @@ retaining their spending power. Note that you can spend your ada normally at any time, regardless of how you delegated it. This mechanism will enable stakeholders to participate in the slot leader election process in each epoch. -Stake delegation gives rise to *stake pools* that act in the similar way to +Stake delegation gives rise to *stake pools* that act similarly to mining pools in the Bitcoin protocol. Stake pool operators (SPOs) *must* be online to generate blocks if they are selected as slot leaders. -### Stake delegation requirements +There are three options ada holders can consider for delegating their stake: + +1. Run their own stake pool +2. Agree with a third party to run a private stake pool for them +3. Delegate to other stake pools. + +## Stake delegation requirements Delegating stake requires posting two certificates to the chain: a staking -address registration, and a [delegation certificate](https://docs.cardano.org/operating-a-stake-pool/creating-keys-and-certificates/#creatinganoperationalcertificateandregisteringastakepool). Posting certificates +address registration, and a delegation certificate. Posting certificates requires funds, so a user setting up their first wallet will need a bootstrapping mechanism. This mechanism relies on the possibility of base addresses using a [staking key](https://github.com/input-output-hk/cardano-rosetta/tree/master/examples#staking-key-registration-and-delegation) before posting the registration certificate for that key. Note that the stake address can be based either on a single key or on a script such as [multi-sig](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/simple-scripts.md#multi-signature-scripts). -### Delegation scheme +## Delegation scheme With the concept of delegation, any stakeholder can allow a stake pool to -generate blocks for the Cardano network. Then the rewards will be paid by the -protocol for all participants, including the fees for the SPO. A -stake holder delegates to a particular pool ID, which is the hash of the -operator's [verification key](https://docs.cardano.org/learn/cardano-keys/#vrfkeys). +generate blocks for the Cardano network. Then the protocol will distribute the rewards to all participants, including the fees for the SPO. A +stakeholder delegates to a particular pool ID, which is the hash of the +operator's [verification key](/learn/cardano-keys/#vrfkeys). To limit the delegate’s block generation power to a certain range of epochs and slots, the stakeholder can limit the proxy signing key’s valid @@ -45,7 +50,7 @@ can verify that a proxy signing key was actually issued by a specific stakeholder to a specific delegate, and that the delegate can only use these keys to sign messages inside the key’s valid message space, respectively. -The funds belonging to one staking key of a user’s wallet requires posting a +The funds belonging to one staking key of a user’s wallet require posting a single transaction, containing a delegation certificate. This will only incur the usual transaction fees. In particular, a stakeholder needs to pay a deposit for registering a stake address and not for the stake delegation itself. Once a @@ -55,7 +60,7 @@ delegation choice. Note that the stakeholder's stake will count for the pool's stake during the reward calculation. -### Stake delegation scenario +## Stake delegation scenario Imagine a user who is about to receive their first ada, through redemption, from a trade on an exchange, or some other source. They will set up a new wallet, and @@ -67,3 +72,14 @@ After receiving the initial funds, the user can then participate in staking, by posting a staking key registration certificate, and a delegation certificate for their staking key. Once the key is registered, newly created addresses can be pointer addresses to the staking key registration certificate. + +:::info + +Related topics: + +- [Operating a stake pool](https://developers.cardano.org/docs/operate-a-stake-pool/) +- [Advice for stakeholders - delegators and stake pool operators](https://iohk.io/en/blog/posts/2020/11/13/the-general-perspective-on-staking-in-cardano/) +- [How to stake your ada](https://www.essentialcardano.io/infographic/how-to-stake-your-ada) + +::: + diff --git a/docs/03-learn/05-pledging-rewards.mdx b/docs/03-learn/05-pledging-rewards.mdx index 717f8196..2353de4a 100644 --- a/docs/03-learn/05-pledging-rewards.mdx +++ b/docs/03-learn/05-pledging-rewards.mdx @@ -3,25 +3,24 @@ title: Pledging and rewards metaTitle: Pledging and rewards --- -## Pledging ## - Pledging is an important mechanism that encourages the growth of a healthy -ecosystem within the [Cardano blockchain](https://cardano.org/). When you register a stake pool you can +ecosystem within the Cardano blockchain. When you register a stake pool you can choose to pledge some, or all, of your ada to the pool, to make it more -attractive to people that want to delegate. Although pledging is not required -when [setting up a stake pool](https://docs.cardano.org/operating-a-stake-pool/creating-a-stake-pool/), it can make the stake pool more attractive to delegators, as the higher the amount of ada that is pledged, the higher the +attractive to people who want to delegate. Although pledging is not required +when setting up a stake pool, it can make the pool more attractive to delegators, as the higher the amount of ada that is pledged, the higher the rewards that will be paid out. The a0 protocol parameter defines the influence of the pledge on the pool reward. -## Distributing rewards ## +## Distributing rewards + +During each epoch, rewards are distributed amongst all stakeholders who have delegated to a stake pool, either to their own stake pool, or another pool. These rewards are auto-generated by the protocol and are not managed by the stake pool operators (SPOs). Rewards come from two sources: -During each epoch, rewards are distributed amongst all stakeholders who have delegated to a stake pool, either to their own stake pool, or another pool. These rewards are auto-generated by the protocol itself, and are not managed by the stake pool operators (SPOs). Rewards come from two sources: * All transaction fees: collated from the set of transactions included in a block that was minted during that epoch. * Monetary expansion: involves distinguishing between the total supply of ada and the maximal supply of ada. The total supply consists of all ada currently in circulation, plus the ada in the treasury. The maximal supply is the maximal amount of ada that can ever exist. The difference between these two figures is called the *reserve*. During each epoch, a fixed but parameterizable percentage of the remaining reserve is taken from the reserve and used for epoch rewards and treasury, where the amount being sent to the treasury is a fixed percentage of the amount taken from the reserve. -Learn more about rewards sharing in the [Rewards sharing and pledge on Cardano video](https://www.youtube.com/watch?v=EAzyN3H8MOA&t=7s). +Learn more about rewards sharing in the [rewards sharing and pledge on Cardano video](https://www.youtube.com/watch?v=EAzyN3H8MOA&t=7s). -The following formula outlines how the rewards mechanism works. The available rewards amount, transaction fees, plus monetary expansion, is denoted by R. +The following formula outlines how the reward mechanism works. The available rewards amount, transaction fees, plus monetary expansion, are denoted by R. First, the share of all available rewards that a specific pool can receive is determined, as follows: ![pledge_formula](pledge_formula.png) @@ -42,20 +41,21 @@ Note that z0, σ and s are all relative, so they are fractions of the total supply, as they all lie between zero and one. Two important considerations are: -1. Rewards increase with σ, but stop increasing once σ reaches z0, that is. once the pool becomes saturated. -2. If a0, (the pledge influence,) is zero, this formula simply becomes R·σ’, - so it is proportional to pool stake, up to the point of saturation. For larger values of a0, the pledge s becomes more important. + +1. Rewards increase with σ, but stop increasing once σ reaches z0, that is once the pool becomes saturated. +2. If a0 (the pledge influence) is zero, this formula simply becomes R·σ’, + so it is proportional to the pool's stake, up to the point of saturation. For larger values of a0, the pledge s becomes more important. -Remember that the pledge is declared during pool registration, (alongside the cost and margin values), -and has to be honored by the pool owners who are delegating to the pool: -If they collectively delegate less than the declared pledge, pool rewards for that epoch will be zero. Note that the pool will be public, if its operator margin is set to less than 100%. +Remember that the pledge is declared during pool registration (alongside the cost and margin values), +and has to be honored by the pool owners who are delegating to the pool. +If they collectively delegate less than the declared pledge, pool rewards for that epoch will be zero. Note that the pool will be public if its operator margin is set to less than 100%. -The rewards that are produced by this formula are now adjusted by pool +The rewards that are produced by this formula are now adjusted by pool's performance: we multiply by β/σa, where β is the fraction of all blocks produced by the pool during the epoch and σa is the stake delegated to the pool relative to -the active stake (i.e. total stake that is correctly delegated to a non-retired pool). +the active stake (ie, total stake that is correctly delegated to a non-retired pool). -For an optimally performing pool (that is, a pool producing all the blocks that it can produce), +For an optimally performing pool (a pool producing all the blocks that it can produce), this factor will be 1, on average. The actual value will fluctuate due to the stochastic nature, or random process of the [Ouroboros Praos](https://eprint.iacr.org/2017/573.pdf) consensus algorithm. @@ -65,21 +65,14 @@ are distributed amongst the pool operator and the pool members, or people who delegated part, or all of their stake, to the pool. This happens in several steps: -- First, the declared costs are subtracted and given to the pool operator. -- Next, the declared margin is subtracted and given to the pool operator. -- Finally the remainder is split fairly (proportional to delegated stake), - amongst all people who delegated to the pool, including the pool owners. +- First, the declared costs are subtracted and given to the pool operator +- Next, the declared margin is subtracted and given to the pool operator +- Finally, the remainder is split fairly (proportional to delegated stake), + amongst all stakeholders who delegated to the pool, including the pool owners. -A pledging calculator is available to use for estimation purposes. The rewards -predicted by this calculator _are only an estimate_. The actual amount of ada +The actual amount of ada received in rewards may vary, and will depend on a number of factors including; the actual stake pool performance, that is, the number of blocks a stake pool is observed to produce in a given epoch versus the number it was *expected* to produce. Changes to network parameters may also affect rewards. -The annualized equivalent returns given by this calculator assume that stake is -delegated to the same stake pool for a 365-day period, and that stake pool -performance and other settings are consistent over that timeframe. IOHK accepts -no responsibility for any discrepancy between estimated and actual rewards. - -*Disclaimer*: this calculator is provided for guidance only. diff --git a/docs/03-learn/06-pledging-and-delegation-options.mdx b/docs/03-learn/06-pledging-and-delegation-options.mdx deleted file mode 100644 index 4efc525e..00000000 --- a/docs/03-learn/06-pledging-and-delegation-options.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Pledging and delegation options -metaTitle: Pledging and delegation options ---- - -Ada held on the [Cardano network](https://cardano.org/) represents a user’s -stake in the protocol, the size of which is proportional to the amount of ada -held. Users who hold a stake in Cardano can earn passive rewards for validating -blocks. The amount of rewards they can earn is proportional to the amount of ada -they pledge or delegate to a stake pool. - -There are three options ada holders can consider for delegating their stake: - -1. Run their own stake pool -2. Agree with a third party to run a private stake pool for them -3. Delegate to other stake pools - -To create and register a stake pool, see -[these instructions](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/stake-pool-operations/8_register_stakepool.md). - -Stake pools must maintain **high-availability**, which means that they should -_always_ be online and available to validate and create new blocks. The rewards -a stake pool can earn are directly proportional to the amount of ada that is -pledged or delegated, and the number of blocks the stake pool can create in a -given epoch. Ouroboros elects the slot leader that grants the permissions to -validate transactions and create new blocks, based on the above criteria. - -> Note: It is **strongly recommended** to test all stake pool functionality on -> the [testnet](https://testnets.cardano.org/en/testnets/cardano/overview/) > -> _prior_ to any mainnet deployment. - -### Pledging - -The pledge is the amount of ada that the stake pool operator ‘delegates’ to -their own pool when it is created. This pledge represents the operator's -commitment to maintain their pool and support network activity. Making a pledge -is not required, however, it is recommended to pledge _some_ ada to the stake -pool prior to running it. The more ada that is pledged, the higher the pool -rewards, which are dependent on the pool’s level of uptime and its performance. - -> **Related topics:** -> -> - [Pledging and rewards](/learn/pledging-rewards) - -### Delegation - -Ada holders who do not have technical expertise in maintaining a stake pool can -earn rewards by delegating to any stake pool available on the network. The -[Daedalus wallet](https://docs.cardano.org/cardano-components/daedalus-wallet) -provides a user-friendly interface that allows users to start delegating to any -registered stake pool. - -> Note: ada holders and stake pool operators (SPOs) who pledge or delegate will -> always have access to their ada. If the delegated ada is spent or removed from -> the pool, the rewards decrease accordingly. - -> **Related topics:** -> -> - [Registering a stake pool](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/stake-pool-operations/8_register_stakepool.md) - -> **Further reading:** -> -> - [Advice for Stakeholders - Delegators and Stake Pool Operators](https://iohk.io/en/blog/posts/2020/11/13/the-general-perspective-on-staking-in-cardano/) - -### Rewards - -Delegators earn rewards for participating in staking (either pledging or -delegating), and these rewards are automatically distributed between the -participants according to the rewards scheme. The rewards scheme in Cardano is -designed to be decentralized, which means that there is no single controlling -party. - -> **Related documentation:** -> -> - [Withdrawing rewards](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/stake-pool-operations/11_withdraw-rewards.md) - -### FAQs - -1. **Q: How do I create and register a stake pool?** - - **A**: Please review the steps in the documentation - [here.](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/stake-pool-operations/1_getConfigFiles_AND_Connect.md) - -1. **Q: How do I generate staking addresses?** - - **A**: Please review the steps in the documentation - [here.](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/stake-pool-operations/5_register_key.md) - -1. **Q: How do I determine an optimal amount of ada to pledge to each pool?** - - **A**: This is a personal preference, the more you pledge the higher the - rewards. - -1. **Q: How do I know if my pool is oversaturated?** - - **A**: If the amount of ada delegated to the pool is over 32 million, the - pool is oversaturated. - -1. **Q: How do I know who has delegated to my pool?** - - **A**: You can query the ledger state. - -1. **Q: How can I calculate rewards?** - - **A**: This is calculated automatically by the Ouroboros protocol. - -1. **Q: How can I verify whether my pool was successfully registered on - mainnet?** - - **A**: You can check [pooltool.io](https://pooltool.io/) or run the following - curl command: - -``` -curl -X POST -H "Content-Type: application/json" -d '{"query": "query getStake_pool($id: StakePoolID!){ stakePools(limit: 1 where: { id: { _eq: $id } }){ id } }","variables":{"id":"$My_Pool_id_here"}}' https://explorer.cardano.org/graphql: -``` diff --git a/docs/03-learn/07-consensus-explained.mdx b/docs/03-learn/07-consensus-explained.mdx index f13cf326..8becf0c8 100644 --- a/docs/03-learn/07-consensus-explained.mdx +++ b/docs/03-learn/07-consensus-explained.mdx @@ -9,27 +9,22 @@ Blockchains create consensus by allowing participants to bundle transactions tha The protocol has three main responsibilities: -- Perform a leader check and decide if a block should be produced -- Handle chain selection -- Verify produced blocks +- perform a leader check and decide if a block should be produced +- handle chain selection +- verify produced blocks. ## About Ouroboros -Cardano runs on the Ouroboros consensus protocol, which was delivered with several peer-reviewed papers presented at top-tier conferences and publications in the area of cybersecurity and cryptography. Rather than relying on 'miners' (as in proof-of-work protocols) to solve computationally complex equations to create new blocks – and rewarding the first to do so – proof of stake selects [stake pools to create new blocks](https://docs.cardano.org/learn/cardano-node/#howdoesitwork) based on the stake they control in the network. +Cardano runs on the Ouroboros consensus protocol, which was delivered with several peer-reviewed papers presented at top-tier conferences and publications in the area of cybersecurity and cryptography. Rather than relying on 'miners' (as in proof-of-work protocols) to solve computationally complex equations to create new blocks – and rewarding the first to do so – proof of stake selects [stake pools to create new blocks](/learn/cardano-node/#howdoesitwork) based on the stake they control in the network. ## How Ouroboros works Ouroboros divides time on Cardano into epochs where each epoch is divided into slots. A slot is a short period of time in which a block can be created. Grouping slots into epochs is central to adjusting the leader election process to the dynamically changing stake distribution. -Central to Ouroboros’ design is that it must retain its security in the presence of attacks. As such, the protocol has built-in tolerance to prevent attackers from propagating alternative versions of the blockchain and assumes that an adversary may send arbitrary messages to any participant at any time. The protocol is guaranteed to be secure in the so-called synchronous setting (that is, with strong guarantees on message delivery times) so long as more than 51% of the stake is controlled by honest participants (that is, those following the protocol). +Central to Ouroboros’ design is that it must retain its security in the presence of attacks. As such, the protocol has built-in tolerance to prevent attackers from propagating alternative versions of the blockchain and assumes that an adversary may send arbitrary messages to any participant at any time. The protocol is guaranteed to be secure in the so-called synchronous setting (that is, with strong guarantees on message delivery times) so long as more than 51% of the stake is controlled by honest participants (ie, those following the protocol). A slot leader is elected for each slot, who is responsible for adding a block to the chain and passing it to the next slot leader. To protect against adversarial attempts to subvert the protocol, each new slot leader is required to consider the last few blocks of the received chain as transient: only the chain that precedes the prespecified number of transient blocks is considered settled. This is also referred to as the settlement delay. Among other things, this means that a stakeholder can go offline and still be synced to the blockchain, so long as it’s not for more than the settlement delay. Within the Ouroboros protocol, each network node stores a copy of the transaction mempool – where transactions are added if they are consistent with existing transactions – and the blockchain. The locally stored blockchain is replaced when the node becomes aware of an alternative, longer valid chain. -Read more about the different versions of Ouroboros here: - -- [Ouroboros overview](https://docs.cardano.org/learn/ouroboros-overview) -- [From Classic to Chronos: the implementations of Ouroboros explained](https://iohk.io/en/blog/posts/2022/06/03/from-classic-to-chronos-the-implementations-of-ouroboros-explained/) -- [Ouroboros Chronos provides the first high-resilience, cryptographic time source based on blockchain technology](https://iohk.io/en/blog/posts/2021/10/27/ouroboros-chronos-provides-the-first-high-resilience-cryptographic-time-source-based-on-blockchain/) blog post -- [Ouroboros Genesis: enhanced security in a dynamic environment](https://iohk.io/en/blog/posts/2023/02/09/ouroboros-genesis-enhanced-security-in-a-dynamic-environment/) blog post. +Read the following section to learn more about the different types of Ouroboros. diff --git a/docs/03-learn/08-ouroboros-overview.mdx b/docs/03-learn/08-ouroboros-overview.mdx index 7d7dafc7..b9081b9f 100644 --- a/docs/03-learn/08-ouroboros-overview.mdx +++ b/docs/03-learn/08-ouroboros-overview.mdx @@ -3,26 +3,23 @@ title: Ouroboros overview metaTitle: Ouroboros overview --- -## Ouroboros - In mythology, [Ouroboros (also, *uroboros*)](https://en.wikipedia.org/wiki/Ouroboros) is usually depicted as a snake (or sometimes a dragon) eating its own tail in a closed circle. The word *Ouroboros* itself derives from Ancient Greek, its literal meaning being 'tail eating' or 'tail devourer.' -As a symbol, Ouroboros represents the infinity of time flowing back unto itself, in a never-ending cycle, as if caught in an eternal loop. Ouroboros first appeared in Egypt, in 13th century BC. Later, alchemists adopted Ouroboros into their mystical symbolism. - -Throughout the ages, Ouroboros has been interpreted and used in a variety of ways by a plethora of cultures. One of the most common interpretations is that the symbol represents the interconnectedness and infinity of the Universe. +As a symbol, Ouroboros represents the infinity of time flowing back unto itself, in a never-ending cycle, as if caught in an eternal loop. Ouroboros first appeared in Egypt, in the 13th century BC. Later, alchemists adopted Ouroboros into their mystical symbolism. -In 2017, [Charles Hoskinson](https://en.wikipedia.org/wiki/Charles_Hoskinson) adopted Ouroboros to name the [proof-of-stake](https://docs.cardano.org/new-to-cardano/proof-of-stake) consensus protocol that underlies Cardano. In this context, Ouroboros represents the possibility of infinite and ethical growth and scalability of the blockchain. Ouroboros' central message is the delivery of greater opportunities for the world, and its preservation through [much-reduced energy consumption](https://iohk.io/en/blog/posts/2021/08/17/why-they-re-calling-cardano-the-green-blockchain/). +Throughout the ages, Ouroboros has been interpreted and used in a variety of ways by a plethora of cultures. One of the most common interpretations is that the symbol represents the interconnectedness and infinity of the universe. +In 2017, [Charles Hoskinson](https://en.wikipedia.org/wiki/Charles_Hoskinson) adopted Ouroboros to name the proof-of-stake consensus protocol underlying Cardano. In this context, Ouroboros represents the possibility of infinite and ethical growth and scalability of the blockchain. Ouroboros' central message is the delivery of greater opportunities for the world, and its preservation through [much-reduced energy consumption](https://iohk.io/en/blog/posts/2021/08/17/why-they-re-calling-cardano-the-green-blockchain/). -### What is Ouroboros +## What is Ouroboros [Ouroboros](https://eprint.iacr.org/2016/889.pdf) is the consensus protocol for Cardano, the first provably secure proof-of-stake protocol, and the first blockchain protocol based on peer-reviewed research. -Combining unique technology and mathematically verified mechanisms (including behavioral psychology and economic philosophy principles), Ouroboros guarantees and supports the security and sustainability of any blockchain implementing it. The result is a protocol with proven security guarantees, and able to facilitate the propagation of global, permissionless networks with minimal energy requirements. Cardano is the first such network. +Combining unique technology and mathematically verified mechanisms (including behavioral psychology and economic philosophy principles), Ouroboros guarantees and supports the security and sustainability of any blockchain implementing it. The result is a protocol with proven security guarantees, able to facilitate the propagation of global, permissionless networks with minimal energy requirements. Cardano is the first such network. Ouroboros selects participants - stake pools, in this case - to create new blocks based on the stake they control in the network, and facilitates the creation of distributed, permissionless networks capable of sustainably supporting new markets. -### Ouroboros implementations +## Ouroboros implementations Ouroboros comes in different versions: @@ -31,39 +28,38 @@ Ouroboros comes in different versions: - [Ouroboros Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/) - [Ouroboros Genesis](https://iohk.io/en/research/library/papers/ouroboros-genesiscomposable-proof-of-stake-blockchains-with-dynamic-availability/) - [Ouroboros Crypsinous](https://iohk.io/en/research/library/papers/ouroboros-crypsinousprivacy-preserving-proof-of-stake/) -- [Ouroboros Chronos](https://iohk.io/en/research/library/papers/ouroboros-chronospermissionless-clock-synchronization-via-proof-of-stake/) - -#### Ouroboros Classic +- [Ouroboros Chronos](https://iohk.io/en/research/library/papers/ouroboros-chronospermissionless-clock-synchronization-via-proof-of-stake/). -The first implementation of Ouroboros achieved three major milestones: +### Ouroboros Classic -- The foundation for an energy-efficient protocol to rival proof of work -- The introduction of the mathematical framework to analyze proof of stake -- The implementation of a novel incentive mechanism to reward participants in a proof-of-stake setting +The first implementation of [Ouroboros](https://iohk.io/en/research/library/papers/ouroborosa-provably-secure-proof-of-stake-blockchain-protocol/) achieved three major milestones: -But what really set Ouroboros apart from other blockchain protocols (specifically, proof-of-stake protocols), was its ability to generate unbiased randomness in the protocol’s leader selection algorithm, and the subsequent security assurances that provided. Randomness prevents the formation of patterns, which is critical for maintaining the protocol’s security. Ouroboros was the first blockchain protocol to be developed with this type of rigorous security analysis. +- the foundation for an energy-efficient protocol to rival proof of work +- the introduction of the mathematical framework to analyze proof of stake +- the implementation of a novel incentive mechanism to reward participants in a proof-of-stake setting. +But what really set Ouroboros apart from other blockchain protocols (specifically, proof-of-stake protocols), was its ability to generate unbiased randomness in the protocol’s leader selection algorithm, and the subsequent security assurances that provided. Randomness prevents the formation of patterns, which is critical for maintaining the protocol’s security. Ouroboros was the first blockchain protocol developed with this type of rigorous security analysis. -#### Ouroboros BFT +### Ouroboros BFT -Ouroboros Byzantine Fault Tolerance (BFT) was the protocol's second implementation, used during the Byron update (transition from the old Cardano codebase to the new). The second instance of the protocol prepared Cardano for the decentralization that came with the Shelley release. +[Ouroboros Byzantine Fault Tolerance (BFT)](https://iohk.io/en/research/library/papers/ouroboros-bfta-simple-byzantine-fault-tolerant-consensus-protocol/) was the protocol's second implementation, used during the Byron update (transition from the old Cardano codebase to the new). The second instance of the protocol prepared Cardano for the decentralization that came with the Shelley release. -Ouroboros BFT enabled synchronous communication between a network of federated servers – the blockchain –, providing ledger consensus in a simpler and more deterministic manner. +Ouroboros BFT enabled synchronous communication between a network of federated servers – the blockchain – providing ledger consensus in a simpler and more deterministic manner. -#### Ouroboros Praos +### Ouroboros Praos -Ouroboros Praos introduced substantial security and scalability improvements to the Ouroboros Classic implementation. Praos processes transaction blocks by dividing chains into slots, which are aggregated into epochs. But unlike Ouroboros Classic, Praos is analyzed in a semi-synchronous setting and is secure against adaptive attackers, using private-leader selection and forward-secure, key-evolving signatures to ensure that a strong adversary cannot predict the next slot leader and launch a focused attack (such as a DDoS attack). +[Ouroboros Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/) introduced substantial security and scalability improvements to the Ouroboros Classic implementation. Praos processes transaction blocks by dividing chains into slots, which are aggregated into epochs. But unlike Ouroboros Classic, Praos is analyzed in a semi-synchronous setting and is secure against adaptive attackers, using private-leader selection and forward-secure, key-evolving signatures to ensure that a strong adversary cannot predict the next slot leader and launch a focused attack (such as a DDoS attack). -#### Ouroboros Genesis +### Ouroboros Genesis -Once implemented, the fourth iteration of Ouroboros -Genesis- will further improve upon Ouroboros Praos by adding a novel chain selection rule that enables parties to bootstrap from a genesis block without the need for trusted checkpoints or assumptions about past availability. The Genesis paper also provides proof of the protocol’s Universal Composability, which demonstrates that the protocol can be composed with other protocols in arbitrary configurations in a real-world setting, without losing its security properties. +The fourth iteration of Ouroboros - [Genesis](https://iohk.io/en/research/library/papers/ouroboros-genesiscomposable-proof-of-stake-blockchains-with-dynamic-availability/) - further improves upon Ouroboros Praos by adding a novel chain selection rule that enables parties to bootstrap from a genesis block without the need for trusted checkpoints or assumptions about past availability. The Genesis paper also provides proof of the protocol’s Universal Composability, which demonstrates that the protocol can be composed with other protocols in arbitrary configurations in a real-world setting, without losing its security properties. -#### Ouroboros Crypsinous +### Ouroboros Crypsinous -[Ouroboros Crypsinous](https://iohk.io/en/research/library/papers/ouroboros-crypsinousprivacy-preserving-proof-of-stake/) equips Genesis with privacy-preserving properties. It is the first formally analyzed privacy-preserving proof-of-stake blockchain protocol, which achieves security against adaptive attacks while maintaining strong privacy guarantees by introducing a new coin evolution technique relying on SNARKs and key-private forward-secure encryption. Crypsinous isn’t currently planned to be implemented on Cardano, but it can be used by other chains for increased privacy-preserving settings. +[Ouroboros Crypsinous](https://iohk.io/en/research/library/papers/ouroboros-crypsinousprivacy-preserving-proof-of-stake/) equips Genesis with privacy-preserving properties. It is the first formally analyzed privacy-preserving proof-of-stake blockchain protocol, which achieves security against adaptive attacks while maintaining strong privacy guarantees by introducing a new coin evolution technique relying on Snarks and key-private forward-secure encryption. Crypsinous isn’t currently planned to be implemented on Cardano, but it can be used by other chains for increased privacy-preserving settings. -#### Ouroboros Chronos +### Ouroboros Chronos -[Chronos](https://iohk.io/en/blog/posts/2021/10/27/ouroboros-chronos-provides-the-first-high-resilience-cryptographic-time-source-based-on-blockchain/) achieves two goals: first, it shows how blockchain protocols can synchronize clocks securely via a novel time synchronization mechanism and thereby become independent of external time services. Second, it provides a cryptographically secure source of time to other protocols. In short, Chronos makes the ledger more resistant to attacks that target time information. +[Chronos](https://iohk.io/en/research/library/papers/ouroboros-chronospermissionless-clock-synchronization-via-proof-of-stake/) achieves two goals: first, it shows how blockchain protocols can synchronize clocks securely via a novel time synchronization mechanism and thereby become independent of external time services. Second, it provides a cryptographically secure source of time to other protocols. In short, Chronos makes the ledger more resistant to attacks that target time information. From an application point of view, Chronos can dramatically boost the resilience of critical telecommunications, transport, and other IT infrastructures that require the synchronization of local time to a unified network clock that has no single point of failure. diff --git a/docs/03-learn/09-cardano-keys.mdx b/docs/03-learn/09-cardano-keys.mdx index 957108cc..21bdbe91 100644 --- a/docs/03-learn/09-cardano-keys.mdx +++ b/docs/03-learn/09-cardano-keys.mdx @@ -3,27 +3,29 @@ title: Cardano keys metaTitle: Cardano keys --- -Keys are asymmetric cryptography key pairs used for: +Cardano keys are asymmetric cryptography key pairs used for: -- Signing and validating payments and staking certificates -- Identifying and defining addresses on the Cardano blockchain +- signing and validating payments and staking certificates +- identifying and defining addresses on the Cardano blockchain. This schematic illustrates the relationship between keys, addresses, and certificates: ![keys-certificates](keys-certificates.png) ## Types of keys + In Cardano, there are two main key types: -- Node keys -- Address keys +- node keys +- address keys. ### Node keys -Node keys represent the security of the blockchain and consist of the following keys -- Operator/operational key -- KES key pair -- VRF keys +Node keys represent the security of the blockchain and consist of the following keys: + +- operator/operational key +- key evolving signature (KES) key pair +- verifiable random function (VRF) keys. #### Operator/operational key @@ -33,16 +35,15 @@ It is the responsibility of the operator to manage both the hot (online), and co #### KES key pair -To create an operational certificate for a block-producing node, you need a Key Evolving Signature (KES) key pair, which authenticates who you are. +To create an operational certificate for a block-producing node, you need a KES key pair, which authenticates who you are. A KES key can only evolve for a certain number of periods and becomes useless afterwards. This is useful, because even if an attacker compromises the key and gets access to the signing key, he can only use that to sign blocks from now on, but not blocks dating from earlier periods, making it impossible for the attacker to rewrite history. After the set number of periods has passed, the node operator must generate a new KES key pair, issue a new operational node certificate with that new key pair, and restart the node with the new certificate. - #### VRF keys -Ouroboros Praos adds an extra layer of security to block production via Verifiable Random Function (VRF) keys. +Ouroboros Praos adds an extra layer of security to block production via VRF keys. In other proof-of-stake blockchain protocols (Ouroboros Classic or BFT, for instance), we know who has the right to make the block in each slot, because the slot leader schedule is public. In this case, you only have to prove that you are who you say you are, and everyone can check the public slot leader schedule to verify it. @@ -51,15 +52,22 @@ However, Ouroboros Praos's slot leader schedule is kept private, which means tha The VRF key is a signing verification key stored within the operational certificate. It proves that a node has the right to create a block in a given slot. ### Address keys + Address keys represent the functions of the addresses derived from the keys for identifying funds on the blockchain that consist of the following keys: - Payment key: single address key pair usually used for generating UTXO addresses - Staking key: stake/reward address key pair usually used for generating account/reward addresses. -## Further reading +:::info + +Developer resources: - [Creating keys and addresses](https://github.com/input-output-hk/cardano-node-wiki/wiki/3_keys_and_addresses) - [Creating KES key pair](https://github.com/input-output-hk/cardano-node-wiki/wiki/7_KES_period) - [Generating stake pool keys](https://iohk.zendesk.com/hc/en-us/articles/900001331786-Generate-stake-pool-keys) - [Generating payment/staking keys and address](https://iohk.zendesk.com/hc/en-us/articles/900001219883-Generating-payment-staking-keys-and-address) +::: + + + diff --git a/docs/03-learn/10-cardano-addresses.mdx b/docs/03-learn/10-cardano-addresses.mdx index 0e07104a..4bcad07d 100644 --- a/docs/03-learn/10-cardano-addresses.mdx +++ b/docs/03-learn/10-cardano-addresses.mdx @@ -7,25 +7,25 @@ The addresses are a blake2b-256 hash of the relevant verifying/public keys concatenated with some metadata that can be stored on the [Cardano blockchain](https://cardano.org/). -Shelley introduces four different types of addresses: +Shelley introduced four different types of addresses: - base addresses - pointer addresses - enterprise addresses -- reward account addresses +- reward account addresses. -Besides those new addresses, Shelley continues to support Byron-era _bootstrap +Besides those new addresses, Shelley continued to support Byron-era _bootstrap addresses_ and _script addresses_, but only the new base and pointer addresses -carry stake rights. Therefore, addresses consist of some serialized data +carried stake rights. Therefore, addresses consist of some serialized data specified in the ledger specification stored in the blockchain’s blocks, eg, an Unspent Transaction Output (UTXO) address. The serialized data (address) contains two parts: -- Metadata: used for interpreting. -- Payload: the raw or encoded data. +- metadata: used for interpreting +- payload: the raw or encoded data. -### Base addresses +## Base addresses A base address directly specifies the staking key that should control the stake for that address. The staking rights associated with funds held in this address @@ -33,11 +33,11 @@ may be exercised by the owner of the staking key. Base addresses can be used in transactions without registering the staking key in advance. The stake rights can only be exercised by registering the stake key and -delegating to a [stake pool](/learn/stake-pools). Once the stake key is +delegating to a stake pool. Once the stake key is registered, the stake rights can be exercised for base addresses used in transactions before or after the key registration. -### Pointer addresses +## Pointer addresses A pointer address indirectly specifies the staking key that should control the stake for the address. It references a stake key by a stake key pointer, which @@ -60,7 +60,7 @@ create transactions to pointer addresses before the referenced certificate has become immutable, to prevent funds from being excluded from the proof of stake, in the case of rollbacks. -### Enterprise addresses +## Enterprise addresses Enterprise addresses carry no stake rights, so using these addresses means that you are opting out of participation in the proof-of-stake protocol. @@ -77,7 +77,7 @@ potential adversary. Also note that enterprise addresses may still be used to receive, hold, and send tokens with a policyID (non-ada assets). -### Reward account addresses +## Reward account addresses A reward address is a cryptographic hash of the public staking key of the address. Reward account addresses are used to distribute rewards for @@ -86,10 +86,10 @@ delegation). They have the following properties: -- Account-style accounting is used, not UTXO-style. -- Funds cannot be received via transactions. Instead, their balance is only - increased when rewards are distributed. -- A one-to-one correspondence exists between registered staking keys and reward +- account-style accounting is used, not UTXO-style +- funds cannot be received via transactions; instead, their balance is only + increased when rewards are distributed +- a one-to-one correspondence exists between registered staking keys and reward account addresses. This key is used whenever funds are withdrawn from the address. Furthermore, diff --git a/docs/03-learn/11-about-hard-forks.mdx b/docs/03-learn/11-about-hard-forks.mdx deleted file mode 100644 index 20af4f37..00000000 --- a/docs/03-learn/11-about-hard-forks.mdx +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: About hard forks -metaTitle: About hard forks ---- - -The term _hard fork_ describes a radical change in the blockchain: a change from -one protocol to another, for example. In most blockchains, a hard fork -indicates block changes or a change to their interpretation. - -Traditionally, when conducting a hard fork, the current protocol would stop operating, -new rules and changes would be implemented, and the chain would restart. It is important to -note that a hard-forked chain _will be different_ from the previous version and -that the history of the pre-forked blockchain will no longer be available. - -The [Cardano](https://cardano.org/) blockchain hard forked from a Byron federated model to -a Shelley decentralized one. However, this hard fork was unique. Instead of -implementing radical changes, we ensured a smooth transition to a new protocol -while saving the history of the previous blocks. This means that the chain did -not change *radically*, instead, it contains Byron blocks, and after a transition -period, adds Shelley blocks. There was no fundamental restart point that erased -the history of previous activities. - -### What is a hard fork combinator? -A combinator is a technical term used to indicate the combination of certain -processes or things. In the case of Cardano, a hard fork combinator combines -protocols, thereby enabling the [Byron-to-Shelley transition](https://iohk.io/en/blog/posts/2020/04/29/from-byron-to-shelley-part-one-the-testnets/) without system -interruption or restart. It ensures that Byron and Shelley ledgers appear as *one* -ledger. Shifting from [Ouroboros BFT](https://eprint.iacr.org/2018/1049.pdf) to [Ouroboros Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/) does not require all nodes to -update simultaneously. Instead, nodes can update gradually, in fact, some can -run Byron blocks, while others can run Shelley blocks. - -The hard fork combinator is designed to enable the combination of several -protocols, without having to make significant adjustments. The current Cardano -chain combines Byron and Shelley blocks, and after future transitions, it will -also combine Goguen, Basho, and Voltaire blocks - all as a single property. This -combinator facilitates the transition from Shelley to Goguen and beyond by -simplifying the previous Byron-to-Shelley evolution. - -### Moving from Byron Ouroboros Classic to Shelley Ouroboros Praos -Cardano Byron mainnet ran on the Ouroboros _Classic_ consensus protocol. Cardano -Shelley mainnet, which is the current development era, transitions to a -decentralized network running on the new Ouroboros _Praos_ consensus protocol, -which allows for more extended capabilities while also supporting the staking -process with monetary rewards for ada holders and stake pool owners. - -To enable orderly transitions in Cardano without any diversions in the system, -it was necessary to update the code to support the new protocol’s conditions. -Doing so in a single update might have caused a range of complexities, so -Cardano decided to take a two-stage approach, using the Ouroboros _Byzantine -Fault Tolerance_ (BFT) protocol as an intermediary. - -The shift from Ouroboros Classic to BFT (which happened on February 20, 2020) is -the only traditional hard fork within the Cardano blockchain. This forking event -restarted the Byron mainnet to run the BFT protocol and enable a smoother -transition to Ouroboros Praos without any further chain interruptions. The BFT -protocol was carefully designed so that blockchain history would remain -unchanged, and the blockchain would appear as a single entity. - -### Token locking: Shelley protocol upgrade - -_Token locking_ is a new feature being added to the Shelley protocol to -enable various kinds of smart contract use cases, including creating and -transacting with multi-asset tokens, as well as establishing support for the -Voltaire voting mechanism. - -Token locking is the process of ‘reserving’ a certain amount of assets and -committing not to dispose of them for a specified period of time. This feature -is enabled in the _Allegra_ (token locking) upgrade and will allow recording of -that a specific token is being used for a certain purpose during the _Mary_ -(multi-asset support) upgrade. The _token_ can represent an item that is accounted -for by the blockchain ledger, including ada, but soon will include other custom token types. - -**Token locking: use cases** - -Support for token locking is crucial to enable complex deal settlement and funds -accounting. - -It can be used in the following scenarios: - -- **Contractual agreement** - when someone enters into a contractual agreement, - to sell a property, for instance, it is important to promise that this - property will not be sold to anyone else – only to the person who actually - pays the money. In this case, the token can represent the property and the - ‘promise’ – the actual token locking. If the property is sold to a different - third party, then the contract becomes void. -- **Vote registry** - within the Voltaire voting mechanism, token locking will - enable users to lock a certain amount of their tokens to represent their - voting rights. Ada holders who participate in the voting process will be - required to ‘lock’ their tokens. This will represent their voting rights, - according to the stake that they hold, and eliminate the risks associated with - scenarios such as double-counting votes, allocating more votes than possible, - contradictory votes, or vote duplication. -- **Multi-asset tokens** - Cardano will soon provide support for multi-asset - tokens, where the ledger will support the creation and use of multiple custom - token types, besides ada. Token locking will allow ada tokens to be ‘locked’, - for example, to create another custom asset of equivalent value. - -### Mary: multi-asset support - -*Mary* is the Shelley protocol upgrade implemented in March 2021. It introduced native token and multi-asset support on Cardano. Mary allows users to create uniquely defined (custom) tokens and carry out transactions with them directly on the Cardano blockchain. - -With the Mary upgrade, the ledger’s accounting infrastructure processes not only ada transactions but also transactions that simultaneously carry several asset types. Native support grants distinct advantages for developers as there is no need to create smart contracts to handle custom token creation or transactions. Instead, the accounting ledger tracks the ownership and transfer of assets, removing extra complexity and potential for manual errors, while ensuring significant cost efficiency. - -Developers, businesses, and applications can create general purpose (fungible) or specialized (non-fungible) tokens to achieve commercial or business objectives. These might include the creation of custom payment tokens or rewards for decentralized applications; stablecoins pegged to other currencies; or unique assets that represent intellectual property. All these assets can then be traded, exchanged, or used as payment for products or services. - -**Further reading:** -- [Learn about native tokens](https://docs.cardano.org/native-tokens/learn) - -### Alonzo: smart contract support -*Alonzo* is the protocol upgrade implemented in September 2021, as part of the Goguen development theme. It builds on top of transaction metadata, token locking, and native asset functionality to enable smart contract development. - -This upgrade introduces a versatile platform opening up opportunities for businesses and developers, by allowing the creation of smart contracts and decentralized applications (DApps) for decentralized finance (DeFi). - -Such capability is enabled by adding the necessary tools and the infrastructure using the Plutus Platform. Applying a rigorous approach based on formal methods and verification, Alonzo extends the basic multi-signature scripting language (multisig) used in Cardano Shelley. Multisig is being upgraded to the Plutus Core language for more powerful and secure scripting options. For this, Alonzo implements the [extended unspent transaction output (EUTXO) accounting model](https://iohk.io/en/blog/posts/2021/03/12/cardanos-extended-utxo-accounting-model-part-2/). - -**Further reading:** -- [Smart contracts - here we come](https://iohk.io/en/blog/posts/2021/04/08/smart-contracts-%E2%80%93-here-we-come/) -- [Plutus: what you need to know](https://iohk.io/en/blog/posts/2021/04/13/plutus-what-you-need-to-know/) - -### Vasil: Plutus 2.0 and the debut of pipelining - -Vasil is the protocol upgrade which will be implemented in June 2022. Named after the late Bulgarian mathematician and prominent Cardano community member Vasil Dabov, the Vasil upgrade introduces five key mechanisms to improve the blockchain's performance: [CIP-31](https://cips.cardano.org/cip/CIP-0031) (Reference Inputs), [CIP-32](https://cips.cardano.org/cip/CIP-0032) (Inline Datums), [CIP-33](https://cips.cardano.org/cip/CIP-0033) (Reference Scripts ), [CIP-40](https://cips.cardano.org/cip/CIP-0040) (Collateral Outputs), and diffusion pipelining. - -These improvements boost Cardano's usability and scalability by increasing the block size limit to fit more transactions per block. Developers will have a better experience while building on Cardano as Vasil will greatly reduce the complexity of creating and deploying DApps on Cardano. - -Plutus scripts are also a main focus of the Vasil upgrade. These scripts will live persistently on-chain so they can be referenced when needed which will improve efficiency, as there will no longer be a need to include the script in the transaction attempting to spend its outputs. diff --git a/docs/03-learn/12-chain-confirmation-versus-transaction-confirmation.mdx b/docs/03-learn/12-chain-confirmation-versus-transaction-confirmation.mdx index 3efe8832..e35c9a30 100644 --- a/docs/03-learn/12-chain-confirmation-versus-transaction-confirmation.mdx +++ b/docs/03-learn/12-chain-confirmation-versus-transaction-confirmation.mdx @@ -3,30 +3,26 @@ title: Chain confirmation versus transaction confirmation metaTitle: Chain confirmation versus transaction confirmation --- -### Chain confirmation v transaction confirmation - When discussing [Cardano](https://cardano.org/), often-repeated questions are *what is Cardano’s transaction time?*, and *how many network confirmations does Cardano require before a transaction goes through?* The answers to these questions require a deeper look at the concepts of *chain confirmation* and *transaction confirmation*, and how these relate to the [protocol](https://docs.cardano.org/learn/ouroboros-overview). -**Chain confirmation** +## Chain confirmation -This is *the point beyond which the chain is guaranteed by the protocol not to alter any further because of randomness, or random events.* +This is the point beyond which the chain is guaranteed by the protocol not to alter any further because of randomness, or random events. Chain confirmation occurs at some point in the future, after a certain amount of future k blocks have been minted. The time between now and the point when chain confirmation for a particular transaction occurs is called the *stability window* (that is, the number of slots required for a block to become **stable**, where *stable* is defined as a block that cannot be rolled back). The formula to calculate this window is 3k/f (where k is the security parameter in genesis, and f is the active slot co-efficient parameter in genesis that determines the probability for amount of blocks created in an epoch.) -**Transaction confirmation** +## Transaction confirmation -This is *the point in time when a transaction is accepted into the chain and becomes immutable*. The concepts of block depth and settlement window come into play here. +This is the point in time when a transaction is accepted into the chain and becomes immutable. The concepts of block depth and settlement window come into play here. A transaction can be considered confirmed if the block that contains it is deep enough in the chain. *Deep enough* is a relative concept: the depth of a block indicates how many more blocks have been added to the chain since that particular block was appended to it. And because blocks have depth, so do the transactions contained in them. -If the depth of a particular block is greater than a pre-defined threshold, the transaction is considered to be confirmed, and the assets in that transaction can be used 'safely' (i.e., the protocol guarantees that the transaction has become immutable, so the assets can be traded, exchanged, etc.) +If the depth of a particular block is greater than a pre-defined threshold, the transaction is considered to be confirmed, and the assets in that transaction can be used 'safely' (ie, the protocol guarantees that the transaction has become immutable, so the assets can be traded, exchanged, etc.) The time period that elapses between the point when a transaction is confirmed, and when the transaction's assets can be used to exchange with other assets is called the *settlement window*. -**Likelihood of immutability** +## Likelihood of immutability Another way of determining whether or not a transaction is confirmed is by considering the transaction's *likelihood of immutability*. The probability of a transaction being immutable depends on how many blocks have been added to the chain since that transaction was accepted into the chain. The more blocks added, the higher the probability that the transaction will become immutable. -A transaction becomes immutable as soon as its depth is greater than 3k/f slots (that is, 129600 slots on current mainnet, or 36 hours). If this transaction is inserted into a block at slot 10 for instance, it will only become truly immutable at slot 129600. This is guaranteed by the [Ouroboros Praos protocol](https://eprint.iacr.org/2017/573.pdf). - -However, 3k/f slots normally exceed the requirements in most situations, so a more practical approach is to consider the probability for a transaction to become immutable. In this case, we consider that a transaction is confirmed if the probability for it to become immutable is *high enough*. +A transaction becomes immutable as soon as its depth is greater than 3k/f slots. This is guaranteed by the [Ouroboros Praos protocol](https://eprint.iacr.org/2017/573.pdf). However, 3k/f slots normally exceed the requirements in most situations, so a more practical approach is to consider the probability for a transaction to become immutable. In this case, we consider that a transaction is confirmed if the probability for it to become immutable is *high enough*. diff --git a/docs/03-learn/15-eutxo-explainer.md b/docs/03-learn/15-eutxo-explainer.md index 6a09332f..24444d06 100644 --- a/docs/03-learn/15-eutxo-explainer.md +++ b/docs/03-learn/15-eutxo-explainer.md @@ -1,19 +1,26 @@ --- -title: Understanding the Extended UTXO model +title: Extended UTXO model metaTitle: Understanding the Extended UTXO model --- ->The EUTXO handbook is now out! Deep dive into [Cardano's EUTXO accounting model here](https://ucarecdn.com/3da33f2f-73ac-4c9b-844b-f215dcce0628/EUTXOhandbook_for_EC.pdf). +:::info -Cardano (like Bitcoin) is an Unspent Transaction Output (UTXO)-based blockchain, which utilizes a different accounting model for its ledger from other account-based blockchains like Ethereum. Cardano implements an innovative [Extended Unspent Transaction Output (EUTXO) model](https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/), which is introduced by the Alonzo upgrade to support multi-assets and smart contracts. +The EUTXO handbook is now out! Deep dive into [Cardano's EUTXO accounting model here](https://ucarecdn.com/3da33f2f-73ac-4c9b-844b-f215dcce0628/EUTXOhandbook_for_EC.pdf). + +::: + +Cardano (like Bitcoin) is an Unspent Transaction Output (UTXO)-based blockchain, which utilizes a different accounting model for its ledger from other account-based blockchains like Ethereum. Cardano implements an innovative [Extended Unspent Transaction Output (EUTXO) model](https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/), which was introduced by the Alonzo upgrade to support multi-assets and smart contracts. ## Overview of the UTXO model + In the UTXO model, a transaction has *inputs* and *outputs*, where the inputs are unspent outputs from previous transactions. Assets are stored on the ledger in unspent outputs, rather than in accounts. In abstract terms, think of a transaction as the action that unlocks previous outputs, and creates new ones. ### Transaction output + A transaction output includes an *address* (that you can think of as a lock) and a *value*. In keeping with this analogy, the signature that belongs to the address is the key to unlock the output. Once unlocked, an output can be used as input. New transactions spend outputs of previous transactions, and produce new outputs that can be consumed by future transactions. Each UTXO can only be consumed once, and as a whole. Each output can be spent by exactly one input, and one input *only*. ### Transaction input + A transaction input is the output of a previous transaction. Transaction inputs include a pointer and a cryptographic signature that acts as the unlocking key. The pointer points back to a previous transaction output, and the key unlocks this output. When an output is unlocked by an input, the blockchain marks the unlocked output as 'spent'. New outputs created by a given transaction can then be pointed to by new inputs, and so the chain continues. These new outputs (which have not yet been unlocked, ie, spent) are the UTXOs. Unspent outputs are simply that, outputs that have not yet been spent. In summary, transactions consume unspent outputs from previous transactions, and produce new outputs that can be used as inputs for future transactions. @@ -23,7 +30,9 @@ In summary, transactions consume unspent outputs from previous transactions, and The users' wallets manage these UTXOs and initiate transactions involving the UTXOs owned by the user. Every blockchain node maintains a record of the subset of all UTXOs at all times. This is called the UTXO set. In technical terms, this is the chainstate, which is stored in the data directory of every node. When a new block is added to the chain, the chainstate is updated accordingly. This new block contains the list of latest transactions (including, of course, a record of spent UTXOs, and new ones created since the chainstate was last updated). Every node maintains an exact copy of the chainstate. ## Cardano’s extended UTXO model + The EUTXO model extends the UTXO model in two ways: + 1. It generalizes the concept of ‘address’ by using the lock-and-key analogy. Instead of restricting locks to public keys and keys to signatures, addresses in the EUTXO model can contain arbitrary logic in the form of scripts. For example, when a node validates a transaction, the node determines whether or not the transaction is allowed to use a certain output as an input. The transaction will look up the script provided by the output's address and will execute the script if the transaction can use the output as an input. 2. The second difference between UTXO and EUTXO is that outputs can carry (almost) arbitrary data in addition to an address and value. This makes scripts much more powerful by allowing them to carry state information. @@ -36,6 +45,7 @@ The UTXO model with its graph structure is fundamentally different from the acco EUTXO inherits the per-branches design of the UTXO (Bitcoin) model, where one branch is by definition a sequence of transactions that requires a sequence of validations. To split the logic across different branches and enforce more parallelism, it is essential to build DApps and other solutions using multiple UTXOs. This provides benefits in terms of scaling, just like developing Bitcoin services prerequisites splitting one wallet into sub wallets. ## Advantages of EUTXO + Cardano’s EUTXO model provides a secure and versatile environment to process multiple operations without system failures. This model offers better scalability and privacy, as well as more simplified transaction logic, as each UTXO can only be consumed once and as a whole, which makes transaction verification much simpler. The EUTXO model offers unique advantages over other accounting models. The success or failure of transaction validation depends only on the transaction itself and its inputs, and not on anything else on the blockchain. As a consequence, the validity of a transaction can be checked off-chain, before the transaction is sent to the blockchain. A transaction can still fail if some other transaction concurrently consumes an input that the transaction is expecting, but if all inputs are still present, the transaction is guaranteed to succeed. diff --git a/docs/04-explore-cardano/01-cardano-design-rationale.mdx b/docs/04-explore-cardano/01-cardano-design-rationale.mdx deleted file mode 100644 index e3c2c8b1..00000000 --- a/docs/04-explore-cardano/01-cardano-design-rationale.mdx +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Design rationale -metaTitle: Cardano design rationale ---- - -[Cardano](https://cardano.org/) has been built as a resilient and sustainable -blockchain using the core principles of security, scalability, and -interoperability. Fundamentally, it was designed as a -[proof-of-stake](https://docs.cardano.org/new-to-cardano/proof-of-stake) system, -which means it is undoubtedly more efficient, by orders of magnitude, than proof -of work. Crucially, our ground-breaking proof-of-stake consensus protocol -[Ouroboros](https://iohk.io/en/blog/posts/2020/06/23/the-ouroboros-path-to-decentralization/) -is proven to have the same security guarantees that proof of work has. - -Formal methods, such as mathematical specifications, property-based tests, and -proofs, are the best way to deliver high assurance software systems and give -confidence to users for the management of digital funds. Cardano has been built -using formal methods to get strong guarantees on the functional correctness of -core components of the system. - -Security is one of the founding principles of our blockchain. Cardano is written -in Haskell, a secure functional programming language that encourages building a -system using pure functions. This leads to a design where components are -conveniently testable in isolation. Furthermore, advanced features of Haskell -enable us to employ a whole range of powerful methods for ensuring code -correctness, such as basing the implementation on formal and executable -specifications, extensive property-based testing, and running tests in -simulation. - -For Cardano to deliver a resilient infrastructure on a global scale, it needs to -be able to scale on par with legacy financial systems. Even though we have -designed Cardano with resource efficiency in mind, scaling remains a fundamental -problem for blockchain systems of all kinds. To get towards a solution of the -scaling problem, our researchers have invented our scalability solution -[Hydra](https://eprint.iacr.org/2020/299.pdf), a protocol that can be executed -on top of Cardano, allowing transaction and smart contract processing off the -main chain. This will multiply the capacity of the overall system by a -multitude. - -Performance engineering was used to assess whether design decisions helped us -move closer to the resilience, performance and scalability targets. Distributed -systems performance engineering was applied to anticipate and mitigate issues -associated with long-term, continuous and scalable operations in a real-world -open environment. - -Another major aim in the design of Cardano is to reduce centralization while -actively working against economic incentives that would drive the system towards -centralization. As soon as you have [stake pools](/learn/stake-pools), you have -an economic incentive for these pools to grow, so it was important to make it -less attractive for a stake pool to become too big. It is more cost-efficient to -have a small number of large pools, than a large number of small pools. Cardano -was designed to work against the economic incentive where large pools dominate -the system, by making it less attractive for a pool to become too big. This was -achieved by changing the reward formula. In a naive system, the total rewards -for a pool would be proportional to its stake, so the bigger it gets, the -better. In Cardano, if a pool attracts more stake than a certain threshold (1/k, -where k is a configurable parameter), its reward will no longer increase. So, if -everyone acts in their own self-interest to maximize their rewards, you expect -_k_ pools of roughly equal size. - -The ability to interact with other systems, or interoperability, is a -fundamental design feature of Cardano. One of the current design innovations in -Cardano is the use of sidechains, which means that you can compartmentalize the -system and enable interoperability within the blockchain platform. Data can be -kept off the main chain in what is called a sidechain. Multiple sidechains can -run concurrently, so if one part fails, the rest of the system does not fail, as -it is maintained separately. This results in greater assurance and reliability -within the blockchain. By using sidechains you can transfer assets between -parallel blockchains that operate in different rules, mechanisms or languages -and ways of utilizing the network. - -Governance is also central to the design of Cardano to ensure system -sustainability and adaptability. A well-developed governance strategy will -enable effective, democratic funding for Cardano’s long-term development. The -Cardano treasury system is currently being designed as a sustainable funding -mechanism to maintain Cardano. It will be controlled by the community and will -enable a decentralized, collaborative decision-making process to sustain -Cardano’s development and maintenance. Various potential funding sources will be -used to refill the treasury on a constant basis, such as the aggregation of -newly-minted coins, a percentage of stake pool rewards, transaction fees, and -donations or charity. With funds being accumulated in an iterative process, it -will be possible to fund the project development and pay for improvement -proposals. In addition, Cardano Improvement Proposals (CIPs), will also be -delivered to foster and formalize discussions around new features and their -development within the community. - -Central to the treasury is a democratized voting mechanism where ada holders -will themselves decide how funds are allocated by voting on funding proposals. -This will ensure that decisions are made by a democratic vote rather than by -just a handful of stakeholders. This voting system will influence decisions such -as funding initiatives, authorizing updates to the protocol, and rolling out any -constitutional updates such as changes to the decision-making process, or the -minting of new tokens. diff --git a/docs/05-cardano-testnets/02-about/01-testnet-introduction.mdx b/docs/05-cardano-testnets/02-about/01-testnet-introduction.mdx deleted file mode 100644 index 3d8cf5cd..00000000 --- a/docs/05-cardano-testnets/02-about/01-testnet-introduction.mdx +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Vasil introduction -metaTitle: Vasil introduction ---- - -> Note: New dedicated _preview_ and _pre-production_ environments have been -> recently spun up for the final stages of testing Vasil functionality. These -> environments offer improved chain density and a better developer experience. - -> We recommend that all developers, SPOs, and exchanges use these environments -> rather than the main Cardano testnet. For more details, see -> [environments overview](https://docs.cardano.org/cardano-testnet/getting-started/#environments). - -Vasil enforces the next major upgrade to the Cardano protocol using -[Cardano’s hard fork combinator (HFC) approach](https://docs.cardano.org/learn/about-hard-forks). -This upgrade is named after a much loved and respected Cardano community member, -Vasil St Dabov. - -Vasil brings changes that improve -[the handling of on-chain (Plutus) scripts](https://iohk.io/en/blog/posts/2022/04/13/boosting-cardano-s-throughput-with-script-referencing/), -reducing user costs and allowing -[greater script throughput](https://iohk.io/en/blog/posts/2022/03/21/increasing-the-transaction-throughput-of-cardano/). -Vasil changes form the first stages of a series of planned improvements that -will be rolled out over time. - -More specifically, this upgrade introduces: - -- Diffusion pipelining -- Plutus V2 (a tuned interpreter, and a new cost model) -- New Plutus built-ins -- Plutus reference inputs -- Plutus inline datums -- Plutus reference scripts -- Collateral change address -- Transaction redeemers changes -- Single VRF implementation - -To get started, make sure to: - -- upgrade your - [node configuration, topology, and genesis files](https://book.world.dev.cardano.org/environments.html) -- check the ['Getting started' tutorial](/cardano-testnets/getting-started) -- see - [Vasil testnet tutorials](https://github.com/input-output-hk/Vasil-testnet) -- see - [Babbage script examples](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/plutus/babbage-script-example.md) - -Also, note that: - -- With the Vasil hard fork on mainnet, the _d_ parameter is removed and block - production is now fully decentralized. This prevents re-federation. -- If you are an SPO, you now need to create your operational certificate using - cold.counter +1. The `OpCert` must be exactly one more than the previously - used one. - [See details here](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/stake-pool-operations/7_KES_period.md#warning-vasil-hard-fork-breaking-changes) -- The `minUTxO` formula is now calculated using original bytes instead of - `lovelacePerUTxOWord`. For more details, see - [CIP-55](https://cips.cardano.org/cip/CIP-0055). - -**Feedback** - -We welcome feedback on any issues you have encountered: - -- Via - [Discord channels](https://discord.com/channels/826816523368005654/826816523964383263) - for general questions or discussions. -- Via the - [Cardano node issue tracker](https://github.com/input-output-hk/cardano-node/issues) - for any bugs or feature requests in the node. Please tag them as - Vasil-related. -- Via the - [Plutus issue tracker](https://github.com/input-output-hk/plutus/issues) for - any bugs or feature requests with Plutus. -- Via - [IOG technical support desk](https://iohk.zendesk.com/hc/en-us/categories/900000102203-Shelley-Testnet). - -You can also join -['IO DEV announcements' Telegram channel](https://t.me/IOdevannouncements) to -receive key development updates. diff --git a/docs/05-cardano-testnets/02-about/_category_.yml b/docs/05-cardano-testnets/02-about/_category_.yml deleted file mode 100644 index 6d16debc..00000000 --- a/docs/05-cardano-testnets/02-about/_category_.yml +++ /dev/null @@ -1,4 +0,0 @@ -position: 2 -label: 'About' -collapsible: true -collapsed: true diff --git a/docs/05-evolution/01-cardano-design-rationale.mdx b/docs/05-evolution/01-cardano-design-rationale.mdx new file mode 100644 index 00000000..cacd9bd0 --- /dev/null +++ b/docs/05-evolution/01-cardano-design-rationale.mdx @@ -0,0 +1,26 @@ +--- +title: Design rationale +metaTitle: Cardano design rationale +--- + +[Cardano](https://cardano.org/) is an open source [proof-of-stake](/new-to-cardano/proof-of-stake) blockchain project that began in 2015 to address existing blockchain challenges in the design and development of cryptocurrencies. It aims to provide a more balanced and sustainable ecosystem that better accounts for the needs of its users as well as other systems seeking integration. + +The first generation of blockchains (like Bitcoin) offered decentralized ledgers for secure cryptocurrency transfer. However, such blockchains did not provide a functional environment for complex deal settlement and decentralized application (DApp) development. As blockchain technology matured, the second generation (like Ethereum) provided more enhanced solutions for writing and executing smart contracts, application development, and the creation of different token types. On the other hand, the second generation of blockchains often faces issues in terms of scalability. + +Cardano is conceived as the third-generation blockchain as it combines the properties of the prior generations and evolves to meet all the arising needs of users. When comparing blockchain properties, many aspects should be considered. Thus, the best solution must ensure the highest security, scalability (transaction throughput, data scale, network bandwidth), and functionality (besides transaction processing, the blockchain should provide all means for business deal settlement). Moreover, it is important to ensure that blockchain technology is constantly developing in terms of sustainability and is interoperable with other blockchains and financial institutions. + +To address these needs, Cardano has been built focusing on such core concepts as: + +- **Scalability** – ensures that the Cardano network is capable of processing an increasing number of transactions as user demand grows. Scalability also provides higher bandwidth capabilities to allow transactions to carry a significant amount of supportive data that can be easily managed within the network. For these needs, Cardano is implementing various techniques (like data compression for instance), and introduces such scaling solutions as [Hydra](https://hydra.family/head-protocol/) and [Mithril](https://mithril.network/doc/), for example. Read more about the [research underpinning Cardano's scalability here](https://www.essentialcardano.io/article/an-analysis-of-the-research-underpinning-cardanos-scalability). +- **Interoperability** – ensures the most multi-functional environment for financial, business, or commercial operations by enabling users to interact with different blockchain systems. Cardano aims to support cross-chain transfers, multiple token types, and commonly used smart contract languages. Read more about the concept of [partner chains](https://iohk.io/en/blog/posts/2023/11/03/partner-chains-are-coming-to-cardano/). +- **Sustainability** – designing a proof-of-stake blockchain means it is vital to ensure that the system is self-sustainable. To drive growth and maturity in a truly decentralized manner, Cardano is built to allow the community to maintain its continuous development by participating, proposing, and implementing system improvements. This is now being implemented through [CIP-1694](https://cips.cardano.org/cip/CIP-1694) on-chain governance mechanisms. + +## Cardano advantages + +- **Academic research** – formal methods, such as mathematical specifications, property-based tests, and proofs, are the best way to deliver high assurance software systems and give confidence to users for the management of digital funds. Cardano has been built using formal methods to achieve strong guarantees on the functional correctness of core components of the system. All of the research and technical specifications that underpin Cardano are publicly available, and all Cardano development activity is published online. +- **System design** – Cardano is written in Haskell, a secure functional programming language that encourages building a system using pure functions, which leads to a design where components are conveniently testable in isolation. Advanced features of Haskell enable employing a whole range of powerful methods for ensuring code correctness, such as basing the implementation on formal and executable specifications, extensive property-based testing, and running tests in simulation. +- **Security** – [Ouroboros](https://iohk.io/en/blog/posts/2020/06/23/the-ouroboros-path-to-decentralization/) (the Cardano proof-of-stake protocol) establishes rigorous security guarantees; it was delivered with several peer-reviewed papers presented in top-tier conferences and publications in the area of cybersecurity and cryptography. +- **Energy efficiency** – Cardano is a proof-of-stake blockchain. In contrast to proof-of-work blockchains, [Cardano requires much less energy](https://iohk.io/en/blog/posts/2021/08/17/why-they-re-calling-cardano-the-green-blockchain/) and computational power. The Bitcoin network is secured through computers doing ever-more-energy-intensive computations – proof of work – which is unsustainable in the long term. Cambridge University has an online tool that shows the [computers powering Bitcoin](https://cbeci.org/) already consume more electricity than some countries, like [Switzerland](https://www.bfe.admin.ch/bfe/en/home/supply/statistics-and-geodata/energy-statistics/overall-energy-statistics.html) for example. +- **Seamless upgrades** – traditionally, blockchains upgrade using hard forks. When conducting a hard fork, the current protocol would stop operating, new rules and changes would be implemented, and the chain would restart – with its previous history being erased. Cardano handles hard forks differently. Instead of implementing radical changes, the Cardano [hard fork combinator technology](https://iohk.io/en/blog/posts/2020/05/07/combinator-makes-easy-work-of-shelley-hard-fork/) ensures a smooth transition to a new protocol while saving the history of the previous blocks and not causing any disruptions for end users. +- **Decentralization** – Cardano is maintained by over 3,000 distributed stake pools that are operated by the community. All blocks and transactions are validated by network participants without any reliance on a centralized authority. +- **Functional environment for business use cases** – Cardano is establishing a foundation for global, decentralized finance to develop a range of DApps that can run using functional and domain-specific smart contracts, providing multi-asset tokens for any needs. diff --git a/docs/04-explore-cardano/02-eras-and-phases.mdx b/docs/05-evolution/02-eras-and-phases.mdx similarity index 66% rename from docs/04-explore-cardano/02-eras-and-phases.mdx rename to docs/05-evolution/02-eras-and-phases.mdx index 0bf9240e..c9264453 100644 --- a/docs/04-explore-cardano/02-eras-and-phases.mdx +++ b/docs/05-evolution/02-eras-and-phases.mdx @@ -1,13 +1,17 @@ --- -title: Development phases and eras on Cardano +title: Development phases and eras metaTitle: Development phases and eras on Cardano --- -> This overview is based on [CIP-59](https://cips.cardano.org/cip/CIP-0059). +:::info -Cardano’s development follows a well-defined and clearly communicated roadmap. Firmly based on academic research and rigorous testing, this process has resulted in a chain with zero outages. +This overview is based on [CIP-59](https://cips.cardano.org/cip/CIP-0059). -Cardano has gone through multiple development *phases and eras enabled by [hard fork combinator](https://docs.cardano.org/learn/about-hard-forks) events*. The following concepts are explained below: +::: + +Cardano’s development follows a well-defined and clearly communicated [roadmap](https://roadmap.cardano.org/en/). Firmly based on academic research and rigorous testing, this process has resulted in a chain with zero outages. + +Cardano has gone through multiple development *phases and eras enabled by hard fork combinator events*. The following concepts are explained below: - **Development phase** – a high-level collection of features described on the [Cardano roadmap](https://roadmap.cardano.org/en/). - **Ledger era** – a collection of ledger features introduced with a hard fork. Starting with Alonzo, eras are planned to be named after mathematicians and computer scientists in *a, b,c* order. @@ -19,19 +23,21 @@ Cardano has gone through multiple development *phases and eras enabled by [hard Cardano’s development phases include Byron, Shelley, Goguen, Basho, and Voltaire – all named after poets except for Goguen, a computer scientist. -Byron focused on the foundation establishment, Shelley on decentralization. Goguen introduced smart contracts and native asset support, Basho – scalability enhancements, and, finally, Voltaire is about decentralized governance and decision-making. - -See [Cardano’s development phases overview here](https://docs.cardano.org/new-to-cardano/why-use-cardano/#cardanodevelopmentthemes). + - **Byron**. Byron set the foundation for Cardano development allowing users to buy and sell ada on a proof-of-stake blockchain network. Initially, the Cardano ledger was established as a federated network, where block production and transaction validation were maintained by [the founding entities](https://www.essentialcardano.io/article/founding-and-iog-organization). Byron saw the delivery of [Daedalus](https://daedaluswallet.io/) and Yoroi wallets, and also provided users with a Block Explorer ‒ a tool specifically designed for browsing the blockchain. + - **Shelley**. The Shelley development theme introduced a decentralized ledger creating a completely new economic system, which drives the network’s growth and gradual optimization. Shelley evolved from Byron’s federated network maintenance, with more and more blocks being produced by the distributed stake pool operator community. This theme focused on many critical steps that ensure enhanced user experience in terms of stake pool operation, delegation preferences, and incentives. + - **Goguen**. Goguen development focused on the establishment of a global, financial, and multi-functional system for decentralized application (DApp) building, smart contract support, and custom token issuance. Goguen is a key building block to establish a versatile platform to build solutions around such application domains as supply chain, track and trace, finance, medical records, identity voting, property registration, P2P payments, and many others. + - **Basho**. Basho focuses on Cardano’s optimization in terms of improving the scalability and interoperability of the network. Whereas other development stages focus on decentralization and new functionality, Basho is about improving the underlying performance of the Cardano network to better support growth and adoption for applications with high transaction volume. + - **Voltaire**. Decentralized governance and decision making lie at the heart of Voltaire granting the Cardano community the ability to vote on network development updates, technical improvements, and project funding. For the Cardano network to become more decentralized, it requires not only the distributed infrastructure introduced during Shelley but also the capacity to be maintained and improved over time in a decentralized way. ## Ledger eras There are several eras within the evolution of Cardano. Each era refers to the rules of the ledger. For example, what transaction types and what data is stored in the ledger, or the validity and meaning of the transactions. -**Byron and Shelley eras** +### Byron and Shelley eras The evolution of the Cardano mainnet began with the Byron ledger rules. The mainnet underwent a hard fork in late July 2020 to switch from the Byron rules to the Shelley ledger rules. It was a full reimplementation of Cardano, which enabled two fundamental changes: the support for multiple sets of ledger rules, and the management of the hard fork process of switching from one set of rules to the next. In other words, the new implementation could support both the Byron rules and the Shelley rules, which meant that, when deployed to the mainnet in early 2020, the implementation was fully compatible with the Byron rules. This allowed for a smooth transition from the old to the new implementation. Once all Cardano users had upgraded their nodes to the new implementation, it became possible to invoke the hard fork combinator event and switch to the Shelley rules. -**Allegra, Mary, and Alonzo eras** +### Allegra, Mary, and Alonzo eras Allegra, Mary, and Alonzo eras are all part of the *Goguen development phase.* @@ -41,7 +47,7 @@ Because Goguen features were implemented in steps, each set of functionality was - Allegra: introduced token locking support - Mary: brought native tokens and multi-asset functionality to Cardano -- Alonzo: introduced smart contract support +- Alonzo: introduced smart contract support. The names Allegra and Mary were chosen for their connection to the poet Percy Shelley and were only intended to be used as [variable names](https://github.com/input-output-hk/cardano-ledger/blob/1cbf1fc2bb005a8206e5b5a7cdf44d35baaca455/eras/shelley-ma/impl/src/Cardano/Ledger/Allegra.hs#L40) for a very specific abstraction used in the ledger code. @@ -49,7 +55,7 @@ Goguen, the smart contract development phase, was the only phase named not after Going forward, the teams decided to use names in *a,b,c* order, after individuals who contributed to mathematics and computer science. One lack of consistency to notice is that eras can use both first and last names. This is driven by conciseness. -**Babbage era** +### Babbage era The Babbage ledger era introduced such features as inline datums, reference scripts, and reference inputs. However, the release is also known as *Vasil,* named to honor the late Bulgarian mathematician and Cardano ambassador Vasil Dabov. diff --git a/docs/05-evolution/03-about-hard-forks.mdx b/docs/05-evolution/03-about-hard-forks.mdx new file mode 100644 index 00000000..d2c51f67 --- /dev/null +++ b/docs/05-evolution/03-about-hard-forks.mdx @@ -0,0 +1,36 @@ +--- +title: About hard forks +metaTitle: About hard forks +--- + +The term _hard fork_ describes a radical change in the blockchain: a change from +one protocol to another, for example. In most blockchains, a hard fork +indicates block changes or a change to their interpretation. + +Traditionally, when conducting a hard fork, the current protocol would stop operating, +new rules and changes would be implemented, and the chain would restart. It is important to +note that a hard-forked chain _will be different_ from the previous version and +that the history of the pre-forked blockchain will no longer be available. + +The Cardano blockchain hard forked from a Byron federated model to +a Shelley decentralized one in 2020. However, this hard fork was unique. Instead of +implementing radical changes, Cardano ensured a smooth transition to a new protocol +while saving the history of the previous blocks. This means that the chain did +not change *radically*, instead, it contained Byron blocks, and after a transition +period, added Shelley blocks. There was no fundamental restart point that erased +the history of previous activities. + +## What is a hard fork combinator? + +A combinator is a technical term used to indicate the combination of certain +processes or things. In the case of Cardano, a hard fork combinator combines +protocols, thereby enabling the [era-to-era transition](https://iohk.io/en/blog/posts/2020/04/29/from-byron-to-shelley-part-one-the-testnets/) without system +interruption or restart. It ensured that Byron and Shelley ledgers appeared as *one* +ledger. Shifting from [Ouroboros BFT](https://eprint.iacr.org/2018/1049.pdf) to [Ouroboros Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/) did not require all nodes to +update simultaneously. Instead, nodes could update gradually, in fact, some could +run Byron blocks, while others could run Shelley blocks. + +The hard fork combinator is designed to enable the combination of several +protocols, without having to make significant adjustments. + +Read more about Cardano's upgrades in the following section. diff --git a/docs/05-evolution/04-upgrades/01-byron-to-shelley.mdx b/docs/05-evolution/04-upgrades/01-byron-to-shelley.mdx new file mode 100644 index 00000000..0e9904b5 --- /dev/null +++ b/docs/05-evolution/04-upgrades/01-byron-to-shelley.mdx @@ -0,0 +1,10 @@ +--- +title: Byron to Shelley +metaTitle: Moving from Byron Ouroboros Classic to Shelley Ouroboros Praos +--- + +Cardano's Byron mainnet ran on the [Ouroboros Classic](https://iohk.io/en/research/library/papers/ouroboros-a-provably-secure-proof-of-stake-blockchain-protocol/) consensus protocol. Cardano's Shelley mainnet transitioned to a decentralized network running on the [Ouroboros Praos](https://iohk.io/en/research/library/papers/ouroboros-praos-an-adaptively-secure-semi-synchronous-proof-of-stake-protocol/) consensus protocol, which enabled more extended capabilities while also supporting the staking process with monetary rewards for ada holders and stake pool operators. + +To enable orderly transitions in Cardano without any diversions in the system, it was necessary to update the code to support the new protocol’s conditions. Doing so in a single update might have caused a range of complexities, so Cardano decided to take a two-stage approach, using the Ouroboros _Byzantine Fault Tolerance_ (BFT) protocol as an intermediary. + +The shift from Ouroboros Classic to BFT (which happened on February 20, 2020) is the only traditional hard fork within the Cardano blockchain. This forking event restarted the Byron mainnet to run the BFT protocol and enable a smoother transition to Ouroboros Praos without any further chain interruptions. The BFT protocol was carefully designed so that blockchain history would remain unchanged, and the blockchain would appear as a single entity. diff --git a/docs/05-evolution/04-upgrades/02-allegra.mdx b/docs/05-evolution/04-upgrades/02-allegra.mdx new file mode 100644 index 00000000..f26ca602 --- /dev/null +++ b/docs/05-evolution/04-upgrades/02-allegra.mdx @@ -0,0 +1,26 @@ +--- +title: Allegra +metaTitle: Allegra - token locking +--- + +Allegra was the Shelley protocol upgrade that introduced token locking support to enable various kinds of smart contract use cases. + +Allegra represented a relatively small technical change to the consensus protocol, with a slight impact on the actual ledger. However, it was significant since it prepared the platform for smart contracts and the creation of assets (in addition to ada) that run on Cardano. It also provided an important piece of Voltaire (governance) functionality, supporting a voting mechanism. + +Token locking is a way of recording that a specific token is being used for some purpose. 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). + +:::info + +Read more about token locking [in this blog post.](https://iohk.io/en/blog/posts/2020/12/02/goguen-brings-token-locking-to-cardano/) + +::: + +## Token locking use cases + +Support for token locking is crucial to enable complex deal settlement and funds accounting. + +It can be used in the following scenarios: + +- **Contractual agreement** – when someone enters into a contractual agreement, to sell a property, for instance, it is important to promise that this property will not be sold to anyone else – only to the person who actually pays the money. In this case, the token can represent the property and the ‘promise’ – the actual token locking. If the property is sold to a different third party, then the contract becomes void. +- **Vote registry** – within the Voltaire voting mechanism, token locking will enable users to lock a certain amount of their tokens to represent their voting rights. Ada holders who participate in the voting process will be required to ‘lock’ their tokens. This will represent their voting rights, according to the stake that they hold, and eliminate the risks associated with scenarios such as double-counting votes, allocating more votes than possible, contradictory votes, or vote duplication. +- **Multi-asset tokens** – Cardano provides support for multi-asset tokens, where the ledger supports the creation and use of multiple custom token types, besides ada. Token locking allows ada tokens to be ‘locked’, for example, to create another custom asset of equivalent value. diff --git a/docs/05-evolution/04-upgrades/03-mary.mdx b/docs/05-evolution/04-upgrades/03-mary.mdx new file mode 100644 index 00000000..b88892ca --- /dev/null +++ b/docs/05-evolution/04-upgrades/03-mary.mdx @@ -0,0 +1,17 @@ +--- +title: Mary +metaTitle: Mary - multi-asset support +--- + +*Mary* is the Shelley protocol upgrade implemented in March 2021. It introduced native token and multi-asset support on Cardano. Mary allowed users to create uniquely defined (custom) tokens and carry out transactions with them directly on the Cardano blockchain. + +With the Mary upgrade, the ledger’s accounting infrastructure processes not only ada transactions but also transactions that simultaneously carry several asset types. Native support grants distinct advantages for developers as there is no need to create smart contracts to handle custom token creation or transactions. Instead, the accounting ledger tracks the ownership and transfer of assets, removing extra complexity and potential for manual errors, while ensuring significant cost efficiency. + +Developers, businesses, and applications can create general purpose (fungible) or specialized (non-fungible) tokens to achieve commercial or business objectives. These might include the creation of custom payment tokens or rewards for decentralized applications; stablecoins pegged to other currencies; or unique assets that represent intellectual property. All these assets can then be traded, exchanged, or used as payment for products or services. + +:::info + +Further reading: +- [Learn about native tokens](/native-tokens/learn) + +::: diff --git a/docs/05-evolution/04-upgrades/04-alonzo.mdx b/docs/05-evolution/04-upgrades/04-alonzo.mdx new file mode 100644 index 00000000..d3bd814f --- /dev/null +++ b/docs/05-evolution/04-upgrades/04-alonzo.mdx @@ -0,0 +1,18 @@ +--- +title: Alonzo +metaTitle: Alonzo - smart contract support +--- + +*Alonzo* is the protocol upgrade implemented in September 2021, as part of the Goguen development phase. It built on top of transaction metadata, token locking, and native asset functionality to enable smart contract development. + +This upgrade introduced a versatile platform opening up opportunities for businesses and developers, by allowing the creation of smart contracts and decentralized applications (DApps) for decentralized finance (DeFi). + +Such capability was enabled by adding the necessary tools and the infrastructure using the Plutus platform. Applying a rigorous approach based on formal methods and verification, Alonzo extended the basic multi-signature scripting language (multisig) used in Cardano Shelley. Multisig was upgraded to the Plutus Core language for more powerful and secure scripting options. For this, Alonzo implemented the [extended unspent transaction output (EUTXO) accounting model](https://iohk.io/en/blog/posts/2021/03/12/cardanos-extended-utxo-accounting-model-part-2/). + +:::info + +Further reading: +- [Smart contracts - here we come](https://iohk.io/en/blog/posts/2021/04/08/smart-contracts-%E2%80%93-here-we-come/) +- [Plutus: what you need to know](https://iohk.io/en/blog/posts/2021/04/13/plutus-what-you-need-to-know/) + +::: diff --git a/docs/05-cardano-testnets/02-about/02-feature-overview.mdx b/docs/05-evolution/04-upgrades/05-vasil.mdx similarity index 84% rename from docs/05-cardano-testnets/02-about/02-feature-overview.mdx rename to docs/05-evolution/04-upgrades/05-vasil.mdx index 6f81613b..b3364a6c 100644 --- a/docs/05-cardano-testnets/02-about/02-feature-overview.mdx +++ b/docs/05-evolution/04-upgrades/05-vasil.mdx @@ -1,11 +1,15 @@ --- -title: Vasil feature overview -metaTitle: Vasil feature overview +title: Vasil +metaTitle: Vasil upgrade --- +Vasil is the protocol upgrade implemented in June 2022. Named after the late Bulgarian mathematician and prominent Cardano community member Vasil Dabov, the Vasil upgrade introduced five key mechanisms to improve the blockchain's performance: [CIP-31](https://cips.cardano.org/cip/CIP-0031) (reference inputs), [CIP-32](https://cips.cardano.org/cip/CIP-0032) (inline datums), [CIP-33](https://cips.cardano.org/cip/CIP-0033) (reference scripts), [CIP-40](https://cips.cardano.org/cip/CIP-0040) (collateral outputs), and diffusion pipelining. + +Here's a more detailed feature overview. + ## Diffusion pipelining -Diffusion pipelining is a feature that improves block propagation times and further leads to higher throughput. In essence, it streamlines the process of sharing information about newly created blocks among network participants. The goal of this upgrade is to ensure that blocks can be shared (propagated) in the network within five seconds after their creation. For this, diffusion pipelining propagates blocks before their full validation thus overlapping the time spent on diffusion with the time needed on validation. +Diffusion pipelining is a feature that improves block propagation times and further leads to higher throughput. In essence, it streamlines the process of sharing information about newly created blocks among network participants. The goal is to ensure that blocks can be shared (propagated) in the network within five seconds after their creation. For this, diffusion pipelining propagates blocks before their full validation thus overlapping the time spent on diffusion with the time needed on validation. Pipelining also ensures that the block header referencing the hash of a previous block is propagated correctly. The body of the block is retained within the metadata included in the next block, which is essential for DDoS attack resistance even without full block confirmation. @@ -13,7 +17,7 @@ Diffusion pipelining provides more space for block size increase and Plutus scri ## Plutus Core changes -Plutus Core is a scripting language used in the Cardano ledger. It consists of basic core language constructs and also includes built-in types (integers, strings etc.) and built-in functions (integer addition etc.) that provide functionality that would be difficult or expensive to implement in the Plutus Core code. Built-in functions mostly operate on built-in types. Built-in types come with a size metric that is used by costing functions. For example, the size metric for integers returns the bit-size of the integer. +Plutus Core is a scripting language used in the Cardano ledger. It consists of basic core language constructs and also includes built-in types (integers, strings, etc) and built-in functions (integer addition, etc) that provide functionality that would be difficult or expensive to implement in the Plutus Core code. Built-in functions mostly operate on built-in types. Built-in types come with a size metric that is used by costing functions. For example, the size metric for integers returns the bit-size of the integer. The performance of Plutus Core scripts relates to how expensive it is to run a script in the ledger. The cost model describes CPU and memory fees for each language primitive and can be used off-chain to predict fees for running such scripts. @@ -43,7 +47,7 @@ The updated cost model parameters include the following changes: ### New Plutus Core built-in -The built-in types and type operators remain unchanged from the Alonzo release. All the new built-in functions are backward compatible. Adding them does not break any older script validators. The Vasil release continues to support the Alonzo built-in functions and adds the following new function: +The built-in types and type operators remain unchanged from the Alonzo upgrade. All the new built-in functions are backward compatible. Adding them does not break any older script validators. The Vasil release continues to support the Alonzo built-in functions and adds the following new function: **serialiseData** @@ -57,15 +61,15 @@ For more explanations, how-to guides, and tutorials, see [Plutus Docs.](https:// ### Plutus script addresses -*A Plutus V2 script will not have the same hash value as a Plutus V1 script.* +*A Plutus V2 script does not have the same hash value as a Plutus V1 script.* -Since scripts must match their on-chain hashes exactly, it is important that the scripts which an application uses do not accidentally change. For example, changing the source code or updating dependencies or tooling may lead to small changes in the script. As a result, the hash will change. In cases where the hashes must match exactly, even changes which do not alter the functionality of the script can be problematic. +Since scripts must match their on-chain hashes exactly, it is important that the scripts that an application uses do not accidentally change. For example, changing the source code or updating dependencies or tooling may lead to small changes in the script. As a result, the hash will change. In cases where the hashes must match exactly, even changes which do not alter the functionality of the script can be problematic. In light of this consideration, some DApp developers might expect that when doing a migration from Plutus V1 scripts to Plutus V2 scripts, the same source code, when recompiled, will generate the same hash value of that script address. However, it is impossible for a compiled V2 script to have the same script hash and address as a compiled V1 script. Using the exact same script with different language versions will result in different hashes. The exact same script (as in UPLC.Program) can be used as a Plutus V1 script or a Plutus V2 script, and since the language version is part of the hash, the two hashes will be different. -**A Plutus V1 script will not necessarily have the same hash value when recompiled with a later version of the Plutus Compiler** +**A Plutus V1 script will not necessarily have the same hash value when recompiled with a later version of the Plutus compiler** Suppose you write your Haskell source code (Plutus Tx), compile it into Plutus Core code (PLC), generate its hash value, then use it in a transaction. If you don’t save your compiled code, and then decide to use the same script in the future, you would have to recompile it. This could result in a different hash value of the script address even without upgrading from Plutus V1 to Plutus V2 scripts. This is because the hash is computed based on the output of the compiled code. @@ -75,7 +79,7 @@ Given Plutus compiler version changes, changes in the dependencies, and multiple Once you expect that you will not modify the on-chain part of your application and you don’t want the hash value of your script address to change, the best way to keep it the same is to save the output of your final compiled Plutus Core code (PLC) to a file. -For details on how to export scripts, please see: [How to export scripts, datums and redeemers](https://plutus.readthedocs.io/en/latest/howtos/exporting-a-script.html) in the Plutus Core user documentation. +For details on how to export scripts, please see: [How to export scripts, datums, and redeemers](https://plutus.readthedocs.io/en/latest/howtos/exporting-a-script.html) in the Plutus Core user documentation. ## Reference inputs (CIP-31) @@ -120,15 +124,13 @@ See the [how to reference scripts](https://github.com/perturbing/vasil-tests/blo Two important elements in Plutus are *datums* and *redeemers*. The datum is a piece of information that can be associated with a UTXO and is used to carry script state information. It is frequently used in combination with a redeemer, which is like an instruction or command to the contract. -With the Vasil hard fork, developers will be able to see redeemers for all inputs rather than just the one being passed to the currently executing script. +With the Vasil hard fork, developers can see redeemers for all inputs rather than just the one being passed to the currently executing script. ## Collateral change address Script collateral is the monetary guarantee a user gives to assure that the transaction that uses a contract has been carefully constructed and thoroughly tested before submission to the validators. It is used to guarantee that nodes are compensated for their work in case phase-2 validation fails. The collateral amount is specified at the time of constructing the transaction and is reserved to allow for the on-chain script execution. -Currently, on Cardano mainnet, the collateral amount is set to 150% of the transaction fee, and no change is provided to the collateral UTXO. This means that if a script fails phase-2 validation, the DApp user will lose all the funds that are stored in the UTXO chosen for the collateral. - -With the Vasil hard fork, DApp developers will have the possibility to specify a change address for the script collateral. This means that in case the script fails phase-2 validation, only the right amount will be taken, and the remaining funds will be sent to the provided change address. +With the Vasil hard fork, DApp developers can specify a change address for the script collateral. This means that in case the script fails phase-2 validation, only the right amount will be taken, and the remaining funds will be sent to the provided change address. See the [how to use collateral outputs](https://github.com/perturbing/vasil-tests/blob/main/collateral-output-cip-40.md) tutorial for more details. diff --git a/docs/05-cardano-testnets/02-about/03-secp.mdx b/docs/05-evolution/04-upgrades/06-valentine.mdx similarity index 53% rename from docs/05-cardano-testnets/02-about/03-secp.mdx rename to docs/05-evolution/04-upgrades/06-valentine.mdx index 785fd131..248a9776 100644 --- a/docs/05-cardano-testnets/02-about/03-secp.mdx +++ b/docs/05-evolution/04-upgrades/06-valentine.mdx @@ -1,15 +1,9 @@ --- -title: Valentine (SECP) upgrade +title: Valentine (SECP) metaTitle: Valentine (SECP) upgrade --- -The Valentine (or SECP) upgrade is Cardano’s intra-era hard fork that follows the [Vasil upgrade](https://docs.cardano.org/cardano-testnet/about/testnet-introduction). Valentine is a small and focused semantic change to the ledger, which brings new built-in functions to Plutus to support SECP elliptic curves (ECDSA and Schnorr). Although an intra-era hard fork requires a hard fork combinator event, it does not change the ledger era, which means that this is an upgrade to the Babbage era (Vasil functionality). - -To get started: - -- check the ['Getting started' tutorial](https://docs.cardano.org/cardano-testnet/getting-started) -- track the [ecosystem readiness page for the SECP upgrade](https://iohk.zendesk.com/hc/en-us/articles/14669691361433-Ecosystem-readiness-for-the-SECP-upgrade) -- see [example scripts below](https://docs.cardano.org/cardano-testnet/about/secp/#examplescripts) +The Valentine (or SECP) upgrade is Cardano’s intra-era hard fork that followed the Vasil upgrade. Valentine was a small and focused semantic change to the ledger, which brought new built-in functions to Plutus to support SECP elliptic curves (ECDSA and Schnorr). Although an intra-era hard fork requires a hard fork combinator event, it does not change the ledger era, which means that this was an upgrade to the Babbage ledger era. ## About ECC @@ -21,17 +15,17 @@ Cardano uses the Edwards-curve Digital Signature Algorithm (EdDSA) with elliptic Ed25519 is part of the family of [safeCurves](https://safecurves.cr.yp.to/), which secp256k1 is not part of. The variance in algorithms means that Plutus DApp developers who want to work with other blockchains and need to validate ECDSA and Schnorr signatures would have to spend time, effort, and funds to implement such algorithms over the Standards for Efficient Cryptography (SECP) elliptic curves in Plutus. This extra implementation considerably increases potential security risks. -Since only Cardano’s primary signature algorithm Ed25519 is provided as a Plutus built-in function, ECDSA and Schnorr operations would be more expensive and time-consuming unless also provided as built-in functions. +Since only Cardano’s primary signature algorithm Ed25519 was provided as a Plutus built-in function, ECDSA and Schnorr operations would be more expensive and time-consuming unless also provided as built-in functions. -**What does the SECP upgrade bring?** +**What did the SECP upgrade bring?** -Cardano’s Valentine upgrade adds new built-in functions to Plutus to support ECDSA and Schnorr signatures along with Cardano’s native signature. +Cardano’s Valentine upgrade added new built-in functions to Plutus to support ECDSA and Schnorr signatures along with Cardano’s native signature. -These built-in functions will become native to Cardano, and since they will be implemented and audited by experts, they will provide the highest level of security. This standardization will allow any Plutus DApp developer to widen the choice of multi-signature or threshold signature design to use. +These built-in functions are now native to Cardano, and since they are implemented and audited by experts, they provide the highest level of security. This standardization allows any Plutus DApp developer to widen the choice of multi-signature or threshold signature design to use. [CIP-49](https://github.com/mlabs-haskell/CIPs/blob/c5bdd66fe49c19c341499f86cebaa2eef9e90b74/CIP-0049/README.md) provides a more in-depth oversight of the motivation and specification for the new implementation of built-in functions. -After the new cryptographic primitives implementation, Plutus will be able to easily verify transactions from other blockchains using ECDSA and Schnorr standards. For example, Plutus will be able to natively verify signatures generated in EVM sidechains, which will improve the developer experience in terms of process simplicity, cost, and advanced security. +After the new cryptographic primitives implementation, Plutus can easily verify transactions from other blockchains using ECDSA and Schnorr standards. For example, Plutus can natively verify signatures generated in EVM sidechains, which improves the developer experience in terms of process simplicity, cost, and advanced security. ![cardano-secp](https://ucarecdn.com/7c41014d-2a03-493e-83f1-054c6e3ac78f/) @@ -41,6 +35,12 @@ Below are links to examples of scripts and script data files containing the inpu The use of these scripts is similar to a [token minting process](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/plutus/plutus-minting-script-example.md), where you build a transaction to mint a token using `--mint-script-file` with a provided Plutus script and `--mint-redeemer-file` for provided input script data. -- See the tutorial on [how to use the new SECP256K1 primitives](https://github.com/input-output-hk/Vasil-testnet/blob/main/secp-primitives-cip.md) +:::info + +- See the tutorial on [how to use SECP256K1 primitives](https://github.com/input-output-hk/Vasil-testnet/blob/main/secp-primitives-cip.md) - Alternatively, find [Plutus SECP256k1 examples here](https://gist.github.com/james-iohk/4b54ceefbc3ad3d6fdbc49350bd5b6a8) - And see the [PlutusTx API](https://github.com/input-output-hk/plutus/blob/node/1.35.4/plutus-tx/src/PlutusTx/Builtins.hs#L169-L202). + +::: + + diff --git a/docs/05-evolution/04-upgrades/_category_.yml b/docs/05-evolution/04-upgrades/_category_.yml new file mode 100644 index 00000000..7d14dbb7 --- /dev/null +++ b/docs/05-evolution/04-upgrades/_category_.yml @@ -0,0 +1,4 @@ +position: 4 +label: 'Upgrades explained' +collapsible: true +collapsed: true diff --git a/docs/05-evolution/_category_.yml b/docs/05-evolution/_category_.yml new file mode 100644 index 00000000..6aee6d3d --- /dev/null +++ b/docs/05-evolution/_category_.yml @@ -0,0 +1,4 @@ +position: 5 +label: 'Cardano evolution' +collapsible: true +collapsed: true diff --git a/docs/06-cardano-testnets/02-environments.mdx b/docs/06-cardano-testnets/02-environments.mdx new file mode 100644 index 00000000..ac0e92c3 --- /dev/null +++ b/docs/06-cardano-testnets/02-environments.mdx @@ -0,0 +1,42 @@ +--- +title: Testnet environments +metaTitle: Testnet environments +--- + + +Discover the various testnet environments available on Cardano to select the one best suited for your testing needs. + +## Early-stage testing networks + +### SanchoNet + +SanchoNet is an early-stage testnet environment for testing CIP-1694 on-chain governance mechanisms. + +- [**SanchoNet configurations**](https://book.world.dev.cardano.org/env-sanchonet.html) + +### Preview + +Preview is the network environment for testing release candidates +and expanded test scenarios. Preview is meant for DApps, stake pool operators +(SPOs), and exchanges who wish to test mature release candidates. + +- [**Preview configurations**](https://book.world.dev.cardano.org/env-preview.html) + +## Late-stage testing networks + +### Pre-production + +Pre-production is the most mature network for testing purposes, which resembles +a production (mainnet) environment. It is meant for exchanges, SPOs, +pre-deployment DApps, and wallets that wish to test release functionality before +deploying on mainnet. + +- [**Pre-production configurations**](https://book.world.dev.cardano.org/env-preprod.html) + +### Production network (mainnet) + +Production is the live network, also referred to as mainnet. It features +official functionality releases. Exchanges, SPOs, DApps, wallets, and end users +can use the mainnet for development, transaction processing, and other needs. + +- [**Production configurations**](https://book.world.dev.cardano.org/env-mainnet.html) diff --git a/docs/05-cardano-testnets/03-getting-started.mdx b/docs/06-cardano-testnets/03-getting-started.mdx similarity index 66% rename from docs/05-cardano-testnets/03-getting-started.mdx rename to docs/06-cardano-testnets/03-getting-started.mdx index e1592341..a7fb6dc5 100644 --- a/docs/05-cardano-testnets/03-getting-started.mdx +++ b/docs/06-cardano-testnets/03-getting-started.mdx @@ -3,10 +3,6 @@ title: Getting started with Cardano testnets metaTitle: Getting started with the Cardano testnets --- -> Note that the **Cardano testnet** is no longer recommended for testing -> purposes. The community is encouraged to use preview and pre-production -> testnet environments explained below. - To get started and join Cardano testnets, you should install and configure the Cardano node and the command line interface (CLI), configure your testing environment, and generate payment keys and addresses. Note, that you will also @@ -39,7 +35,7 @@ choice of the best-matching method depends on the operating system, level of technical expertise, and personal preferences. Building the node using Nix is the recommended method, as this is what IOG’s -internal development teams use and is considered the most reliable. +internal development teams use and consider the most reliable. For more information on the various options, see: @@ -56,56 +52,17 @@ network has experienced thus far. These configurations tell the node how to handle the updates that come with each era (ie, Mary, Alonzo, Babbage, etc). Each new era (implemented using the -[hard fork combinator technology](https://docs.cardano.org/learn/about-hard-forks)) +hard fork combinator technology) introduces protocol changes and new ledger rules. While old configurations are still valid, the new configurations and features offer new rules and -improvements. In the Babbage era, for example, Plutus v2 scripts work better -than Plutus v1 scripts. Plutus v1 scripts, however, are still supported. +improvements. In the Babbage era, for example, Plutus V2 scripts work better +than Plutus V1 scripts. Plutus V1 scripts, however, are still supported. For more details, see: - [Understanding configuration files](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/getting-started/understanding-config-files.md) - [Configuring the node using YAML](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/configuring-a-node-using-yaml.md) -## Environments - -### Early-stage testing networks - -**Devnet** - -Devnet is the network for early involvement and functionality testing before a -release candidate is mature. It is meant for projects such as DApps that wish to -explore new features as soon as they are available. - -[**Devnet configurations**](https://book.world.dev.cardano.org/environments.html#vasil-dev) - -**Preview** - -Preview is the longer-term network environment for testing release candidates -and expanded test scenarios. Preview is meant for DApps, stake pool operators -(SPOs), and exchanges who wish to test mature release candidates. - -[**Preview configurations**](https://book.world.dev.cardano.org/environments.html#preview-testnet) - -### Late-stage testing networks - -**Pre-production** - -Pre-production is the most mature network for testing purposes, which resembles -a production (mainnet) environment. It is meant for exchanges, SPOs, -pre-deployment DApps, and wallets that wish to test release functionality before -deploying on mainnet. - -[**Pre-production configurations**](https://book.world.dev.cardano.org/environments.html#pre-production-testnet) - -**Production network (mainnet)** - -Production is the live network, also referred to as mainnet. It features -official functionality releases. Exchanges, SPOs, DApps, wallets, and end users -can use the mainnet for development, transaction processing, and other needs. - -[**Production configurations**](https://book.world.dev.cardano.org/environments.html#production-mainnet) - ## Working with the Cardano testnets Note that mainnet and testnet commands are very similar except for the flag @@ -115,7 +72,6 @@ use the `--testnet-magic INTEGER` flag instead. `INTEGER` indicates the number of the testnet: -- Vasil devnet integer is `9` - Preview integer is `2` - Pre-production integer is `1` @@ -157,11 +113,15 @@ For more commands, see: - [Creating keys and addresses](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/stake-pool-operations/3_keys_and_addresses.md) +:::note + Note to use the `--testnet-magic INTEGER` flag instead of `--mainnet`. +::: + ### Funding the address using a faucet -To fund your testnet address, go to the testnet faucet and request some test +To fund your testnet address, go to the testnets faucet and request some test ada: - [The testnet faucet](/cardano-testnets/tools/faucet) @@ -176,6 +136,5 @@ run the following command to fund your address: You’re now ready to create, sign, and submit transactions on testnets. See the tutorial: -- [Building and signing transactions](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/building-and-signing-tx.md) +- [Building and signing transactions.](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/building-and-signing-tx.md) -Note to use the `--testnet-magic INTEGER` flag instead of `--mainnet`. diff --git a/docs/05-cardano-testnets/04-local-testnet.mdx b/docs/06-cardano-testnets/04-local-testnet.mdx similarity index 100% rename from docs/05-cardano-testnets/04-local-testnet.mdx rename to docs/06-cardano-testnets/04-local-testnet.mdx diff --git a/docs/05-cardano-testnets/05-daedalus-testnet.mdx b/docs/06-cardano-testnets/05-daedalus-testnet.mdx similarity index 100% rename from docs/05-cardano-testnets/05-daedalus-testnet.mdx rename to docs/06-cardano-testnets/05-daedalus-testnet.mdx diff --git a/docs/05-cardano-testnets/06-tools/01-faucet.mdx b/docs/06-cardano-testnets/06-tools/01-faucet.mdx similarity index 100% rename from docs/05-cardano-testnets/06-tools/01-faucet.mdx rename to docs/06-cardano-testnets/06-tools/01-faucet.mdx diff --git a/docs/05-cardano-testnets/06-tools/02-staking-calculator.mdx b/docs/06-cardano-testnets/06-tools/02-staking-calculator.mdx similarity index 100% rename from docs/05-cardano-testnets/06-tools/02-staking-calculator.mdx rename to docs/06-cardano-testnets/06-tools/02-staking-calculator.mdx diff --git a/docs/05-cardano-testnets/06-tools/03-plutus-fee-estimator.mdx b/docs/06-cardano-testnets/06-tools/03-plutus-fee-estimator.mdx similarity index 100% rename from docs/05-cardano-testnets/06-tools/03-plutus-fee-estimator.mdx rename to docs/06-cardano-testnets/06-tools/03-plutus-fee-estimator.mdx diff --git a/docs/05-cardano-testnets/06-tools/_category_.yml b/docs/06-cardano-testnets/06-tools/_category_.yml similarity index 100% rename from docs/05-cardano-testnets/06-tools/_category_.yml rename to docs/06-cardano-testnets/06-tools/_category_.yml diff --git a/docs/05-cardano-testnets/07-resources.mdx b/docs/06-cardano-testnets/07-resources.mdx similarity index 99% rename from docs/05-cardano-testnets/07-resources.mdx rename to docs/06-cardano-testnets/07-resources.mdx index c7a0bd15..036dd299 100644 --- a/docs/05-cardano-testnets/07-resources.mdx +++ b/docs/06-cardano-testnets/07-resources.mdx @@ -44,5 +44,9 @@ posts which you may find helpful: - [Plutus Pioneers program notes](https://plutus-pioneer-program.readthedocs.io/en/latest/plutus_pioneer_program.html) - [Developer resources on Essential Cardano](https://www.essentialcardano.io/developer) +:::tip + If you have produced material and would like to contribute your content for inclusion on this page, please raise a pull request. + +::: diff --git a/docs/05-cardano-testnets/08-support-feedback.mdx b/docs/06-cardano-testnets/08-support-feedback.mdx similarity index 100% rename from docs/05-cardano-testnets/08-support-feedback.mdx rename to docs/06-cardano-testnets/08-support-feedback.mdx diff --git a/docs/05-cardano-testnets/index.mdx b/docs/06-cardano-testnets/index.mdx similarity index 96% rename from docs/05-cardano-testnets/index.mdx rename to docs/06-cardano-testnets/index.mdx index 69775dc0..96cea9ec 100644 --- a/docs/05-cardano-testnets/index.mdx +++ b/docs/06-cardano-testnets/index.mdx @@ -1,7 +1,7 @@ --- title: Cardano testnets metaTitle: Cardano testnets -sidebar_position: 4 +sidebar_position: 6 collapsible: true collapsed: true --- diff --git a/docs/06-development-guidelines/01-installing-the-cardano-node.mdx b/docs/07-development-guidelines/01-installing-the-cardano-node.mdx similarity index 100% rename from docs/06-development-guidelines/01-installing-the-cardano-node.mdx rename to docs/07-development-guidelines/01-installing-the-cardano-node.mdx diff --git a/docs/06-development-guidelines/02-cardano-node-course.mdx b/docs/07-development-guidelines/02-cardano-node-course.mdx similarity index 100% rename from docs/06-development-guidelines/02-cardano-node-course.mdx rename to docs/07-development-guidelines/02-cardano-node-course.mdx diff --git a/docs/06-development-guidelines/03-node-tests.mdx b/docs/07-development-guidelines/03-node-tests.mdx similarity index 100% rename from docs/06-development-guidelines/03-node-tests.mdx rename to docs/07-development-guidelines/03-node-tests.mdx diff --git a/docs/06-development-guidelines/04-node-monitoring.mdx b/docs/07-development-guidelines/04-node-monitoring.mdx similarity index 100% rename from docs/06-development-guidelines/04-node-monitoring.mdx rename to docs/07-development-guidelines/04-node-monitoring.mdx diff --git a/docs/06-development-guidelines/05-use-cli.mdx b/docs/07-development-guidelines/05-use-cli.mdx similarity index 100% rename from docs/06-development-guidelines/05-use-cli.mdx rename to docs/07-development-guidelines/05-use-cli.mdx diff --git a/docs/06-development-guidelines/07-transaction-tutorials/02-minting-transaction.mdx b/docs/07-development-guidelines/07-transaction-tutorials/02-minting-transaction.mdx similarity index 100% rename from docs/06-development-guidelines/07-transaction-tutorials/02-minting-transaction.mdx rename to docs/07-development-guidelines/07-transaction-tutorials/02-minting-transaction.mdx diff --git a/docs/06-development-guidelines/07-transaction-tutorials/03-stake-transaction.mdx b/docs/07-development-guidelines/07-transaction-tutorials/03-stake-transaction.mdx similarity index 100% rename from docs/06-development-guidelines/07-transaction-tutorials/03-stake-transaction.mdx rename to docs/07-development-guidelines/07-transaction-tutorials/03-stake-transaction.mdx diff --git a/docs/06-development-guidelines/07-transaction-tutorials/04-withdraw-transaction.mdx b/docs/07-development-guidelines/07-transaction-tutorials/04-withdraw-transaction.mdx similarity index 100% rename from docs/06-development-guidelines/07-transaction-tutorials/04-withdraw-transaction.mdx rename to docs/07-development-guidelines/07-transaction-tutorials/04-withdraw-transaction.mdx diff --git a/docs/06-development-guidelines/07-transaction-tutorials/05-redelegate-transaction.mdx b/docs/07-development-guidelines/07-transaction-tutorials/05-redelegate-transaction.mdx similarity index 100% rename from docs/06-development-guidelines/07-transaction-tutorials/05-redelegate-transaction.mdx rename to docs/07-development-guidelines/07-transaction-tutorials/05-redelegate-transaction.mdx diff --git a/docs/06-development-guidelines/07-transaction-tutorials/06-multiple-purposes.mdx b/docs/07-development-guidelines/07-transaction-tutorials/06-multiple-purposes.mdx similarity index 100% rename from docs/06-development-guidelines/07-transaction-tutorials/06-multiple-purposes.mdx rename to docs/07-development-guidelines/07-transaction-tutorials/06-multiple-purposes.mdx diff --git a/docs/06-development-guidelines/07-transaction-tutorials/index.mdx b/docs/07-development-guidelines/07-transaction-tutorials/index.mdx similarity index 100% rename from docs/06-development-guidelines/07-transaction-tutorials/index.mdx rename to docs/07-development-guidelines/07-transaction-tutorials/index.mdx diff --git a/docs/06-development-guidelines/_category_.yml b/docs/07-development-guidelines/_category_.yml similarity index 84% rename from docs/06-development-guidelines/_category_.yml rename to docs/07-development-guidelines/_category_.yml index f66b6c09..916376b8 100644 --- a/docs/06-development-guidelines/_category_.yml +++ b/docs/07-development-guidelines/_category_.yml @@ -1,4 +1,4 @@ -position: 5 +position: 7 label: 'Development guidelines' collapsible: true collapsed: true diff --git a/docs/07-operating-a-stake-pool/01-stake-pool-operations-101.mdx b/docs/08-operating-a-stake-pool/01-stake-pool-operations-101.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/01-stake-pool-operations-101.mdx rename to docs/08-operating-a-stake-pool/01-stake-pool-operations-101.mdx diff --git a/docs/07-operating-a-stake-pool/02-about-stake-pools.mdx b/docs/08-operating-a-stake-pool/02-about-stake-pools.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/02-about-stake-pools.mdx rename to docs/08-operating-a-stake-pool/02-about-stake-pools.mdx diff --git a/docs/07-operating-a-stake-pool/03-creating-a-stake-pool.mdx b/docs/08-operating-a-stake-pool/03-creating-a-stake-pool.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/03-creating-a-stake-pool.mdx rename to docs/08-operating-a-stake-pool/03-creating-a-stake-pool.mdx diff --git a/docs/07-operating-a-stake-pool/04-node-connectivity.mdx b/docs/08-operating-a-stake-pool/04-node-connectivity.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/04-node-connectivity.mdx rename to docs/08-operating-a-stake-pool/04-node-connectivity.mdx diff --git a/docs/07-operating-a-stake-pool/05-creating-keys-and-certificates.mdx b/docs/08-operating-a-stake-pool/05-creating-keys-and-certificates.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/05-creating-keys-and-certificates.mdx rename to docs/08-operating-a-stake-pool/05-creating-keys-and-certificates.mdx diff --git a/docs/07-operating-a-stake-pool/06-public-stake-pools.mdx b/docs/08-operating-a-stake-pool/06-public-stake-pools.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/06-public-stake-pools.mdx rename to docs/08-operating-a-stake-pool/06-public-stake-pools.mdx diff --git a/docs/07-operating-a-stake-pool/07-SMASH.mdx b/docs/08-operating-a-stake-pool/07-SMASH.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/07-SMASH.mdx rename to docs/08-operating-a-stake-pool/07-SMASH.mdx diff --git a/docs/07-operating-a-stake-pool/08-performance.mdx b/docs/08-operating-a-stake-pool/08-performance.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/08-performance.mdx rename to docs/08-operating-a-stake-pool/08-performance.mdx diff --git a/docs/07-operating-a-stake-pool/09-ranking.mdx b/docs/08-operating-a-stake-pool/09-ranking.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/09-ranking.mdx rename to docs/08-operating-a-stake-pool/09-ranking.mdx diff --git a/docs/07-operating-a-stake-pool/10-guidelines-for-large-spos.mdx b/docs/08-operating-a-stake-pool/10-guidelines-for-large-spos.mdx similarity index 100% rename from docs/07-operating-a-stake-pool/10-guidelines-for-large-spos.mdx rename to docs/08-operating-a-stake-pool/10-guidelines-for-large-spos.mdx diff --git a/docs/07-operating-a-stake-pool/_category_.yml b/docs/08-operating-a-stake-pool/_category_.yml similarity index 84% rename from docs/07-operating-a-stake-pool/_category_.yml rename to docs/08-operating-a-stake-pool/_category_.yml index 88cbaeed..3f3835c7 100644 --- a/docs/07-operating-a-stake-pool/_category_.yml +++ b/docs/08-operating-a-stake-pool/_category_.yml @@ -1,4 +1,4 @@ -position: 7 +position: 8 label: 'Operating a stake pool' collapsible: true collapsed: true diff --git a/docs/08-cardano-components/01-cardano-node.mdx b/docs/09-cardano-components/01-cardano-node.mdx similarity index 100% rename from docs/08-cardano-components/01-cardano-node.mdx rename to docs/09-cardano-components/01-cardano-node.mdx diff --git a/docs/08-cardano-components/02-cardano-graphql.mdx b/docs/09-cardano-components/02-cardano-graphql.mdx similarity index 100% rename from docs/08-cardano-components/02-cardano-graphql.mdx rename to docs/09-cardano-components/02-cardano-graphql.mdx diff --git a/docs/08-cardano-components/03-cardano-rosetta/01-about-cardano-rosetta.mdx b/docs/09-cardano-components/03-cardano-rosetta/01-about-cardano-rosetta.mdx similarity index 100% rename from docs/08-cardano-components/03-cardano-rosetta/01-about-cardano-rosetta.mdx rename to docs/09-cardano-components/03-cardano-rosetta/01-about-cardano-rosetta.mdx diff --git a/docs/08-cardano-components/03-cardano-rosetta/02-learn.mdx b/docs/09-cardano-components/03-cardano-rosetta/02-learn.mdx similarity index 100% rename from docs/08-cardano-components/03-cardano-rosetta/02-learn.mdx rename to docs/09-cardano-components/03-cardano-rosetta/02-learn.mdx diff --git a/docs/08-cardano-components/03-cardano-rosetta/03-get-started-rosetta.mdx b/docs/09-cardano-components/03-cardano-rosetta/03-get-started-rosetta.mdx similarity index 100% rename from docs/08-cardano-components/03-cardano-rosetta/03-get-started-rosetta.mdx rename to docs/09-cardano-components/03-cardano-rosetta/03-get-started-rosetta.mdx diff --git a/docs/08-cardano-components/03-cardano-rosetta/04-api-calls-rosetta.mdx b/docs/09-cardano-components/03-cardano-rosetta/04-api-calls-rosetta.mdx similarity index 100% rename from docs/08-cardano-components/03-cardano-rosetta/04-api-calls-rosetta.mdx rename to docs/09-cardano-components/03-cardano-rosetta/04-api-calls-rosetta.mdx diff --git a/docs/08-cardano-components/03-cardano-rosetta/_category_.yml b/docs/09-cardano-components/03-cardano-rosetta/_category_.yml similarity index 100% rename from docs/08-cardano-components/03-cardano-rosetta/_category_.yml rename to docs/09-cardano-components/03-cardano-rosetta/_category_.yml diff --git a/docs/08-cardano-components/04-cardano-ledger-specs.mdx b/docs/09-cardano-components/04-cardano-ledger-specs.mdx similarity index 100% rename from docs/08-cardano-components/04-cardano-ledger-specs.mdx rename to docs/09-cardano-components/04-cardano-ledger-specs.mdx diff --git a/docs/08-cardano-components/05-cardano-db-sync/01-about-db-sync.mdx b/docs/09-cardano-components/05-cardano-db-sync/01-about-db-sync.mdx similarity index 100% rename from docs/08-cardano-components/05-cardano-db-sync/01-about-db-sync.mdx rename to docs/09-cardano-components/05-cardano-db-sync/01-about-db-sync.mdx diff --git a/docs/08-cardano-components/05-cardano-db-sync/02-db-sync-components.mdx b/docs/09-cardano-components/05-cardano-db-sync/02-db-sync-components.mdx similarity index 100% rename from docs/08-cardano-components/05-cardano-db-sync/02-db-sync-components.mdx rename to docs/09-cardano-components/05-cardano-db-sync/02-db-sync-components.mdx diff --git a/docs/08-cardano-components/05-cardano-db-sync/03-db-sync-set-up.mdx b/docs/09-cardano-components/05-cardano-db-sync/03-db-sync-set-up.mdx similarity index 100% rename from docs/08-cardano-components/05-cardano-db-sync/03-db-sync-set-up.mdx rename to docs/09-cardano-components/05-cardano-db-sync/03-db-sync-set-up.mdx diff --git a/docs/08-cardano-components/05-cardano-db-sync/04-best-practices.mdx b/docs/09-cardano-components/05-cardano-db-sync/04-best-practices.mdx similarity index 100% rename from docs/08-cardano-components/05-cardano-db-sync/04-best-practices.mdx rename to docs/09-cardano-components/05-cardano-db-sync/04-best-practices.mdx diff --git a/docs/08-cardano-components/05-cardano-db-sync/05-big-query.mdx b/docs/09-cardano-components/05-cardano-db-sync/05-big-query.mdx similarity index 100% rename from docs/08-cardano-components/05-cardano-db-sync/05-big-query.mdx rename to docs/09-cardano-components/05-cardano-db-sync/05-big-query.mdx diff --git a/docs/08-cardano-components/05-cardano-db-sync/_category_.yml b/docs/09-cardano-components/05-cardano-db-sync/_category_.yml similarity index 100% rename from docs/08-cardano-components/05-cardano-db-sync/_category_.yml rename to docs/09-cardano-components/05-cardano-db-sync/_category_.yml diff --git a/docs/08-cardano-components/06-cardano-wallet.mdx b/docs/09-cardano-components/06-cardano-wallet.mdx similarity index 100% rename from docs/08-cardano-components/06-cardano-wallet.mdx rename to docs/09-cardano-components/06-cardano-wallet.mdx diff --git a/docs/08-cardano-components/07-smash.mdx b/docs/09-cardano-components/07-smash.mdx similarity index 100% rename from docs/08-cardano-components/07-smash.mdx rename to docs/09-cardano-components/07-smash.mdx diff --git a/docs/08-cardano-components/08-ouroboros-network.mdx b/docs/09-cardano-components/08-ouroboros-network.mdx similarity index 100% rename from docs/08-cardano-components/08-ouroboros-network.mdx rename to docs/09-cardano-components/08-ouroboros-network.mdx diff --git a/docs/08-cardano-components/09-cardano-rtview.mdx b/docs/09-cardano-components/09-cardano-rtview.mdx similarity index 100% rename from docs/08-cardano-components/09-cardano-rtview.mdx rename to docs/09-cardano-components/09-cardano-rtview.mdx diff --git a/docs/08-cardano-components/10-cardano-serialization-lib.mdx b/docs/09-cardano-components/10-cardano-serialization-lib.mdx similarity index 100% rename from docs/08-cardano-components/10-cardano-serialization-lib.mdx rename to docs/09-cardano-components/10-cardano-serialization-lib.mdx diff --git a/docs/08-cardano-components/11-daedalus-wallet.mdx b/docs/09-cardano-components/11-daedalus-wallet.mdx similarity index 100% rename from docs/08-cardano-components/11-daedalus-wallet.mdx rename to docs/09-cardano-components/11-daedalus-wallet.mdx diff --git a/docs/08-cardano-components/12-cardano-explorer.mdx b/docs/09-cardano-components/12-cardano-explorer.mdx similarity index 100% rename from docs/08-cardano-components/12-cardano-explorer.mdx rename to docs/09-cardano-components/12-cardano-explorer.mdx diff --git a/docs/08-cardano-components/_category_.yml b/docs/09-cardano-components/_category_.yml similarity index 83% rename from docs/08-cardano-components/_category_.yml rename to docs/09-cardano-components/_category_.yml index 32034e08..bdcb6a82 100644 --- a/docs/08-cardano-components/_category_.yml +++ b/docs/09-cardano-components/_category_.yml @@ -1,4 +1,4 @@ -position: 8 +position: 9 label: 'Cardano components' collapsible: true collapsed: true diff --git a/docs/09-cardano-sidechains/01-getting-started/01-introduction-sidechains.mdx b/docs/10-cardano-sidechains/01-getting-started/01-introduction-sidechains.mdx similarity index 100% rename from docs/09-cardano-sidechains/01-getting-started/01-introduction-sidechains.mdx rename to docs/10-cardano-sidechains/01-getting-started/01-introduction-sidechains.mdx diff --git a/docs/09-cardano-sidechains/01-getting-started/02-ouroboros-description.mdx b/docs/10-cardano-sidechains/01-getting-started/02-ouroboros-description.mdx similarity index 100% rename from docs/09-cardano-sidechains/01-getting-started/02-ouroboros-description.mdx rename to docs/10-cardano-sidechains/01-getting-started/02-ouroboros-description.mdx diff --git a/docs/09-cardano-sidechains/01-getting-started/04-block-explorer.mdx b/docs/10-cardano-sidechains/01-getting-started/04-block-explorer.mdx similarity index 100% rename from docs/09-cardano-sidechains/01-getting-started/04-block-explorer.mdx rename to docs/10-cardano-sidechains/01-getting-started/04-block-explorer.mdx diff --git a/docs/09-cardano-sidechains/01-getting-started/_category_.yml b/docs/10-cardano-sidechains/01-getting-started/_category_.yml similarity index 100% rename from docs/09-cardano-sidechains/01-getting-started/_category_.yml rename to docs/10-cardano-sidechains/01-getting-started/_category_.yml diff --git a/docs/09-cardano-sidechains/02-sidechain-toolkit/01-mainchain-plutus-scripts.mdx b/docs/10-cardano-sidechains/02-sidechain-toolkit/01-mainchain-plutus-scripts.mdx similarity index 100% rename from docs/09-cardano-sidechains/02-sidechain-toolkit/01-mainchain-plutus-scripts.mdx rename to docs/10-cardano-sidechains/02-sidechain-toolkit/01-mainchain-plutus-scripts.mdx diff --git a/docs/09-cardano-sidechains/02-sidechain-toolkit/03-chain-follower.mdx b/docs/10-cardano-sidechains/02-sidechain-toolkit/03-chain-follower.mdx similarity index 100% rename from docs/09-cardano-sidechains/02-sidechain-toolkit/03-chain-follower.mdx rename to docs/10-cardano-sidechains/02-sidechain-toolkit/03-chain-follower.mdx diff --git a/docs/09-cardano-sidechains/02-sidechain-toolkit/04-committee-rotation.mdx b/docs/10-cardano-sidechains/02-sidechain-toolkit/04-committee-rotation.mdx similarity index 100% rename from docs/09-cardano-sidechains/02-sidechain-toolkit/04-committee-rotation.mdx rename to docs/10-cardano-sidechains/02-sidechain-toolkit/04-committee-rotation.mdx diff --git a/docs/09-cardano-sidechains/02-sidechain-toolkit/index.mdx b/docs/10-cardano-sidechains/02-sidechain-toolkit/index.mdx similarity index 100% rename from docs/09-cardano-sidechains/02-sidechain-toolkit/index.mdx rename to docs/10-cardano-sidechains/02-sidechain-toolkit/index.mdx diff --git a/docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/02-create-and-fund-accounts.mdx b/docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/02-create-and-fund-accounts.mdx similarity index 100% rename from docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/02-create-and-fund-accounts.mdx rename to docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/02-create-and-fund-accounts.mdx diff --git a/docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/03-metamask.mdx b/docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/03-metamask.mdx similarity index 100% rename from docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/03-metamask.mdx rename to docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/03-metamask.mdx diff --git a/docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/02-setup-development.mdx b/docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/02-setup-development.mdx similarity index 100% rename from docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/02-setup-development.mdx rename to docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/02-setup-development.mdx diff --git a/docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/03-verify-contract.mdx b/docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/03-verify-contract.mdx similarity index 100% rename from docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/03-verify-contract.mdx rename to docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/03-verify-contract.mdx diff --git a/docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/04-solidity-resources.mdx b/docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/04-solidity-resources.mdx similarity index 100% rename from docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/04-solidity-resources.mdx rename to docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/04-solidity-resources.mdx diff --git a/docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/_category_.yml b/docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/_category_.yml similarity index 100% rename from docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/_category_.yml rename to docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/04-deploy-smart-contracts/_category_.yml diff --git a/docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/05-sidechain-token.mdx b/docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/05-sidechain-token.mdx similarity index 100% rename from docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/05-sidechain-token.mdx rename to docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/05-sidechain-token.mdx diff --git a/docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/06-transferring-tokens.mdx b/docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/06-transferring-tokens.mdx similarity index 100% rename from docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/06-transferring-tokens.mdx rename to docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/06-transferring-tokens.mdx diff --git a/docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/_category_.yml b/docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/_category_.yml similarity index 100% rename from docs/09-cardano-sidechains/03-proof-of-concept-evm-sidechain/_category_.yml rename to docs/10-cardano-sidechains/03-proof-of-concept-evm-sidechain/_category_.yml diff --git a/docs/09-cardano-sidechains/04-support/00-getting-support.mdx b/docs/10-cardano-sidechains/04-support/00-getting-support.mdx similarity index 100% rename from docs/09-cardano-sidechains/04-support/00-getting-support.mdx rename to docs/10-cardano-sidechains/04-support/00-getting-support.mdx diff --git a/docs/09-cardano-sidechains/04-support/01-sidechain-faq.mdx b/docs/10-cardano-sidechains/04-support/01-sidechain-faq.mdx similarity index 100% rename from docs/09-cardano-sidechains/04-support/01-sidechain-faq.mdx rename to docs/10-cardano-sidechains/04-support/01-sidechain-faq.mdx diff --git a/docs/09-cardano-sidechains/04-support/_category_.yml b/docs/10-cardano-sidechains/04-support/_category_.yml similarity index 100% rename from docs/09-cardano-sidechains/04-support/_category_.yml rename to docs/10-cardano-sidechains/04-support/_category_.yml diff --git a/docs/09-cardano-sidechains/_category_.yml b/docs/10-cardano-sidechains/_category_.yml similarity index 82% rename from docs/09-cardano-sidechains/_category_.yml rename to docs/10-cardano-sidechains/_category_.yml index 902c524f..9958bbd0 100644 --- a/docs/09-cardano-sidechains/_category_.yml +++ b/docs/10-cardano-sidechains/_category_.yml @@ -1,4 +1,4 @@ -position: 9 +position: 10 label: 'Cardano sidechains' collapsible: true collapsed: true diff --git a/docs/10-scalability-solutions/01-hydra.mdx b/docs/11-scalability-solutions/01-hydra.mdx similarity index 100% rename from docs/10-scalability-solutions/01-hydra.mdx rename to docs/11-scalability-solutions/01-hydra.mdx diff --git a/docs/10-scalability-solutions/02-mithril.mdx b/docs/11-scalability-solutions/02-mithril.mdx similarity index 100% rename from docs/10-scalability-solutions/02-mithril.mdx rename to docs/11-scalability-solutions/02-mithril.mdx diff --git a/docs/10-scalability-solutions/_category_.yml b/docs/11-scalability-solutions/_category_.yml similarity index 83% rename from docs/10-scalability-solutions/_category_.yml rename to docs/11-scalability-solutions/_category_.yml index 020f1963..0df8e3ba 100644 --- a/docs/10-scalability-solutions/_category_.yml +++ b/docs/11-scalability-solutions/_category_.yml @@ -1,4 +1,4 @@ -position: 10 +position: 11 label: 'Scalability solutions' collapsible: true collapsed: true diff --git a/docs/11-native-tokens/01-learn.mdx b/docs/12-native-tokens/01-learn.mdx similarity index 100% rename from docs/11-native-tokens/01-learn.mdx rename to docs/12-native-tokens/01-learn.mdx diff --git a/docs/11-native-tokens/02-minimum-ada-value-requirement.mdx b/docs/12-native-tokens/02-minimum-ada-value-requirement.mdx similarity index 100% rename from docs/11-native-tokens/02-minimum-ada-value-requirement.mdx rename to docs/12-native-tokens/02-minimum-ada-value-requirement.mdx diff --git a/docs/11-native-tokens/03-getting-started.mdx b/docs/12-native-tokens/03-getting-started.mdx similarity index 100% rename from docs/11-native-tokens/03-getting-started.mdx rename to docs/12-native-tokens/03-getting-started.mdx diff --git a/docs/11-native-tokens/04-exercises.mdx b/docs/12-native-tokens/04-exercises.mdx similarity index 100% rename from docs/11-native-tokens/04-exercises.mdx rename to docs/12-native-tokens/04-exercises.mdx diff --git a/docs/11-native-tokens/05-faqs.mdx b/docs/12-native-tokens/05-faqs.mdx similarity index 100% rename from docs/11-native-tokens/05-faqs.mdx rename to docs/12-native-tokens/05-faqs.mdx diff --git a/docs/11-native-tokens/06-exchange-multi-asset-management-scenarios.mdx b/docs/12-native-tokens/06-exchange-multi-asset-management-scenarios.mdx similarity index 100% rename from docs/11-native-tokens/06-exchange-multi-asset-management-scenarios.mdx rename to docs/12-native-tokens/06-exchange-multi-asset-management-scenarios.mdx diff --git a/docs/11-native-tokens/07-listing-cardano-native-assets-on-an-exchange.mdx b/docs/12-native-tokens/07-listing-cardano-native-assets-on-an-exchange.mdx similarity index 100% rename from docs/11-native-tokens/07-listing-cardano-native-assets-on-an-exchange.mdx rename to docs/12-native-tokens/07-listing-cardano-native-assets-on-an-exchange.mdx diff --git a/docs/11-native-tokens/_category_.yml b/docs/12-native-tokens/_category_.yml similarity index 81% rename from docs/11-native-tokens/_category_.yml rename to docs/12-native-tokens/_category_.yml index 8232c284..e62ba963 100644 --- a/docs/11-native-tokens/_category_.yml +++ b/docs/12-native-tokens/_category_.yml @@ -1,4 +1,4 @@ -position: 11 +position: 12 label: 'Native tokens' collapsible: true collapsed: true diff --git a/docs/11-native-tokens/min-ada.png b/docs/12-native-tokens/min-ada.png similarity index 100% rename from docs/11-native-tokens/min-ada.png rename to docs/12-native-tokens/min-ada.png diff --git a/docs/12-smart-contracts/01-marlowe.mdx b/docs/13-smart-contracts/01-marlowe.mdx similarity index 100% rename from docs/12-smart-contracts/01-marlowe.mdx rename to docs/13-smart-contracts/01-marlowe.mdx diff --git a/docs/12-smart-contracts/01-plutus/01-learn-about-plutus.mdx b/docs/13-smart-contracts/01-plutus/01-learn-about-plutus.mdx similarity index 100% rename from docs/12-smart-contracts/01-plutus/01-learn-about-plutus.mdx rename to docs/13-smart-contracts/01-plutus/01-learn-about-plutus.mdx diff --git a/docs/12-smart-contracts/01-plutus/02-plutus-resources.mdx b/docs/13-smart-contracts/01-plutus/02-plutus-resources.mdx similarity index 100% rename from docs/12-smart-contracts/01-plutus/02-plutus-resources.mdx rename to docs/13-smart-contracts/01-plutus/02-plutus-resources.mdx diff --git a/docs/12-smart-contracts/01-plutus/03-plutus-scripts.mdx b/docs/13-smart-contracts/01-plutus/03-plutus-scripts.mdx similarity index 100% rename from docs/12-smart-contracts/01-plutus/03-plutus-scripts.mdx rename to docs/13-smart-contracts/01-plutus/03-plutus-scripts.mdx diff --git a/docs/12-smart-contracts/01-plutus/04-dapp-development.mdx b/docs/13-smart-contracts/01-plutus/04-dapp-development.mdx similarity index 100% rename from docs/12-smart-contracts/01-plutus/04-dapp-development.mdx rename to docs/13-smart-contracts/01-plutus/04-dapp-development.mdx diff --git a/docs/12-smart-contracts/01-plutus/05-Plutus-use-cases.mdx b/docs/13-smart-contracts/01-plutus/05-Plutus-use-cases.mdx similarity index 100% rename from docs/12-smart-contracts/01-plutus/05-Plutus-use-cases.mdx rename to docs/13-smart-contracts/01-plutus/05-Plutus-use-cases.mdx diff --git a/docs/12-smart-contracts/01-plutus/06-collateral-mechanism.mdx b/docs/13-smart-contracts/01-plutus/06-collateral-mechanism.mdx similarity index 100% rename from docs/12-smart-contracts/01-plutus/06-collateral-mechanism.mdx rename to docs/13-smart-contracts/01-plutus/06-collateral-mechanism.mdx diff --git a/docs/12-smart-contracts/01-plutus/07-transaction-costs-determinism.mdx b/docs/13-smart-contracts/01-plutus/07-transaction-costs-determinism.mdx similarity index 100% rename from docs/12-smart-contracts/01-plutus/07-transaction-costs-determinism.mdx rename to docs/13-smart-contracts/01-plutus/07-transaction-costs-determinism.mdx diff --git a/docs/12-smart-contracts/01-plutus/08-sc-best-practices.mdx b/docs/13-smart-contracts/01-plutus/08-sc-best-practices.mdx similarity index 100% rename from docs/12-smart-contracts/01-plutus/08-sc-best-practices.mdx rename to docs/13-smart-contracts/01-plutus/08-sc-best-practices.mdx diff --git a/docs/12-smart-contracts/01-plutus/Plutus_arch.png b/docs/13-smart-contracts/01-plutus/Plutus_arch.png similarity index 100% rename from docs/12-smart-contracts/01-plutus/Plutus_arch.png rename to docs/13-smart-contracts/01-plutus/Plutus_arch.png diff --git a/docs/12-smart-contracts/01-plutus/_category_.yml b/docs/13-smart-contracts/01-plutus/_category_.yml similarity index 100% rename from docs/12-smart-contracts/01-plutus/_category_.yml rename to docs/13-smart-contracts/01-plutus/_category_.yml diff --git a/docs/12-smart-contracts/02-aiken.mdx b/docs/13-smart-contracts/02-aiken.mdx similarity index 100% rename from docs/12-smart-contracts/02-aiken.mdx rename to docs/13-smart-contracts/02-aiken.mdx diff --git a/docs/12-smart-contracts/_category_.yml b/docs/13-smart-contracts/_category_.yml similarity index 81% rename from docs/12-smart-contracts/_category_.yml rename to docs/13-smart-contracts/_category_.yml index a8a79506..44be46d0 100644 --- a/docs/12-smart-contracts/_category_.yml +++ b/docs/13-smart-contracts/_category_.yml @@ -1,4 +1,4 @@ -position: 12 +position: 13 label: 'Smart contracts' collapsible: true collapsed: true diff --git a/docs/13-community/01-cips.mdx b/docs/14-community/01-cips.mdx similarity index 100% rename from docs/13-community/01-cips.mdx rename to docs/14-community/01-cips.mdx diff --git a/docs/13-community/02-essential-cardano.mdx b/docs/14-community/02-essential-cardano.mdx similarity index 100% rename from docs/13-community/02-essential-cardano.mdx rename to docs/14-community/02-essential-cardano.mdx diff --git a/docs/13-community/03-community-content.mdx b/docs/14-community/03-community-content.mdx similarity index 100% rename from docs/13-community/03-community-content.mdx rename to docs/14-community/03-community-content.mdx diff --git a/docs/13-community/04-Cardano-stack-exchange.mdx b/docs/14-community/04-Cardano-stack-exchange.mdx similarity index 100% rename from docs/13-community/04-Cardano-stack-exchange.mdx rename to docs/14-community/04-Cardano-stack-exchange.mdx diff --git a/docs/13-community/05-ambassador-program.mdx b/docs/14-community/05-ambassador-program.mdx similarity index 100% rename from docs/13-community/05-ambassador-program.mdx rename to docs/14-community/05-ambassador-program.mdx diff --git a/docs/13-community/06-getting-support.mdx b/docs/14-community/06-getting-support.mdx similarity index 100% rename from docs/13-community/06-getting-support.mdx rename to docs/14-community/06-getting-support.mdx diff --git a/docs/13-community/_category_.yml b/docs/14-community/_category_.yml similarity index 80% rename from docs/13-community/_category_.yml rename to docs/14-community/_category_.yml index c7fcb5a1..44f53128 100644 --- a/docs/13-community/_category_.yml +++ b/docs/14-community/_category_.yml @@ -1,4 +1,4 @@ -position: 13 +position: 14 label: 'Community' collapsible: true collapsed: true diff --git a/docs/14-pioneer-programs/01-plutus-pioneers.mdx b/docs/15-pioneer-programs/01-plutus-pioneers.mdx similarity index 100% rename from docs/14-pioneer-programs/01-plutus-pioneers.mdx rename to docs/15-pioneer-programs/01-plutus-pioneers.mdx diff --git a/docs/14-pioneer-programs/_category_.yml b/docs/15-pioneer-programs/_category_.yml similarity index 82% rename from docs/14-pioneer-programs/_category_.yml rename to docs/15-pioneer-programs/_category_.yml index 96665034..48c2cf7f 100644 --- a/docs/14-pioneer-programs/_category_.yml +++ b/docs/15-pioneer-programs/_category_.yml @@ -1,4 +1,4 @@ -position: 14 +position: 15 label: 'Pioneer programs' collapsible: true collapsed: true diff --git a/docs/15-release-notes/02-release-notes.mdx b/docs/16-release-notes/02-release-notes.mdx similarity index 100% rename from docs/15-release-notes/02-release-notes.mdx rename to docs/16-release-notes/02-release-notes.mdx diff --git a/docs/15-release-notes/03-comp-matrix.mdx b/docs/16-release-notes/03-comp-matrix.mdx similarity index 100% rename from docs/15-release-notes/03-comp-matrix.mdx rename to docs/16-release-notes/03-comp-matrix.mdx diff --git a/docs/15-release-notes/Cardano component dependencies 072021.png b/docs/16-release-notes/Cardano component dependencies 072021.png similarity index 100% rename from docs/15-release-notes/Cardano component dependencies 072021.png rename to docs/16-release-notes/Cardano component dependencies 072021.png diff --git a/docs/15-release-notes/Cardano_component_dependencies.png b/docs/16-release-notes/Cardano_component_dependencies.png similarity index 100% rename from docs/15-release-notes/Cardano_component_dependencies.png rename to docs/16-release-notes/Cardano_component_dependencies.png diff --git a/docs/15-release-notes/_category_.yml b/docs/16-release-notes/_category_.yml similarity index 81% rename from docs/15-release-notes/_category_.yml rename to docs/16-release-notes/_category_.yml index df7f5a5d..96007a7d 100644 --- a/docs/15-release-notes/_category_.yml +++ b/docs/16-release-notes/_category_.yml @@ -1,4 +1,4 @@ -position: 15 +position: 16 label: 'Release notes' collapsible: true collapsed: true diff --git a/docs/15-release-notes/comp-dependencies-new.png b/docs/16-release-notes/comp-dependencies-new.png similarity index 100% rename from docs/15-release-notes/comp-dependencies-new.png rename to docs/16-release-notes/comp-dependencies-new.png diff --git a/docs/introduction.mdx b/docs/introduction.mdx index 8e4dc24e..7754d7e1 100644 --- a/docs/introduction.mdx +++ b/docs/introduction.mdx @@ -39,6 +39,6 @@ testing, and running tests in simulation. Cardano's smart contract platform seeks to deliver more advanced features than any protocol previously developed and will serve as a -stable and secure platform for the development of enterprise-level DApps. Cardano's democratic governance system, implemented based on [CIP-1694](https://cips.cardano.org/cip/CIP-1694) on-chain governance mechanisms, will enable the project to evolve over time and sustainably fund itself through a visionary treasury system. +stable and secure platform for the development of enterprise-level DApps. Cardano's democratic governance system, being implemented based on [CIP-1694](https://cips.cardano.org/cip/CIP-1694) on-chain governance mechanisms, will enable the project to evolve over time and sustainably fund itself through a visionary treasury system. You can read more about Cardano on the [official Cardano website](https://cardano.org/) and watch a summary of Cardano's mission in this [explainer video](https://www.youtube.com/watch?v=l_Nv0-PVrnM/). diff --git a/src/pages/index.tsx b/src/pages/index.tsx index 0b17af33..f52d8d19 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -54,7 +54,7 @@ export default function Home(): JSX.Element { heading="Secure, scalable, and interoperable" text="Security is one of the founding principles of Cardano. As it is written in the functional language Haskell, it uses pure functions to build the system, where components can be tested in isolation. More advanced features of Haskell, such as basing the implementation on formal and executable specifications, extensive property-based testing, and running tests in simulation provides a range of powerful methods for ensuring code correctness." label="More on security" - ctalink="/explore-cardano/cardano-design-rationale" + ctalink="/evolution/cardano-design-rationale" Icon={DiamondsIco} />