Add Cardano Sidechains content:NOT TO BE MERGED

content/08-cardano-sidechains.mdx

@@ -0,0 +1,6 @@
+---
+title: Cardano sidechains
+metaTitle: Cardano sidechains
+---
+
+<!-- heading no content -->

content/08-cardano-sidechains/01-basics.mdx

@@ -0,0 +1,6 @@
+---
+title: Getting started
+metaTitle: Getting started
+---
+
+<!-- heading no content -->

content/08-cardano-sidechains/01-basics/01-introduction-sidechains.mdx

@@ -0,0 +1,38 @@
+---
+title: Introduction to sidechains
+metaTitle: Introduction to sidechains
+---
+
+A sidechain is simply a blockchain that runs as a subservient chain to the Cardano main chain. This configuration allows the sidechain to have its own consensus algorithm and features. The sidechain is connected to the main chain through a two-way peg that allows the moving of assets between the chains. The finality of blocks is determined through a consensus mechanism that relies on the security of the main chain.
+
+Input Output group (IOG) provides a sidechain toolkit that is designed to help developers create custom sidechains for a wide range of use cases. To prove the capability of the toolkit, the exemplar application is the Cardano EVM sidechain. EVM stands for Ethereum virtual machine. The Cardano EVM sidechain is EVM-compatible, which means deploying your Ethereum applications is just a matter of deploying your Solidity code on the sidechain and interacting with it through the Web3 API.
+
+## What is the example EVM sidechain?
+The example EVM sidechain project is an open-source Cardano sidechain protocol providing a client written in Scala. The EVM sidechain is a *child sidechain*, meaning that its starting, or genesis block, is seeded from the main chain and the child blockchain depends on the main chain. The example EVM sidechain enables anyone to run a sidechain network passive node.
+## Sidechain advantages
+Sidechains offer advantages in interoperability, scalability, and compatibility.
+### Interoperability
+Sidechains of different types can communicate with each other. The most basic form of communication is the exchange of assets. Because assets retain their nature when transferred to the sidechain, they can be transferred back just as easily. A mechanism called a two-way peg achieves this communication. As long as both chains are secure in themselves, this security is carried on to the two-way transfers.
+Communication between the main chain and the sidechain allows them to keep their disparate consensus methods and block formats and still work together, opening up a much wider range of applications.
+### Scalability
+Just as a project manager has the trilemma of good, fast, or cheap (pick any two), a blockchain has the choice of three competing objectives - decentralization, security, and scalability.
+Because sidechains tend to be short and specific to an application domain, transactions can be completed more quickly, relieving the main chain of this load.
+The scalability improvement of sidechains comes without compromising security and need not affect decentralization, offering improvements in the blockchain trilemma. 
+### Compatibility
+The example EVM sidechain provides a proof of stake (PoS) blockchain running smart contracts written in Solidity. Ethereum smart contracts can run unchanged. The difference is that they will run faster and use a fraction of the resources that they use on a PoW chain. Because they run faster, the expectation is that the end user will pay much less in gas fees.
+## Sidechain design elements
+The design of the example EVM sidechain is based on the principles laid out in the [2018 white paper](https://iohk.io/en/research/library/papers/proof-of-stake-sidechains/) 'Proof-of-Stake Sidechains' by Peter Gazi1, Aggelos Kiayias, and Dionysis Zindros.  
+Here are some design features of the Cardano EVM sidechain relevant to Solidity developers.
+### Two-way peg
+The EVM sidechain allows the transfer of assets back and forth between the Cardano blockchain and sidechains. The two-way peg that achieves this preserves the nature of the asset in both chains whenever the asset moves.
+### Proof of stake
+Although the Solidity contract may be intended for a Proof of Work blockchain, the example EVM sidechain uses the same secure PoS algorithm as Cardano, giving the well-known benefits of reduced energy usage, speed, and decentralization.
+### Firewall 
+The firewall property ensures that a catastrophic failure in one of the chains, such as a violation of its security assumptions, does not make the other chains vulnerable. This feature provides a measure of limited liability analogous to limited liability in the corporate world - when a limited company fails, its stockholders are only liable for the amount of their investment.
+### Merged-staking
+A critical consideration in sidechain construction is safeguarding a new sidechain against attack.
+The example EVM Sidechain construction features 'merged-staking', which allows main-chain validators who have signaled sidechain awareness to create sidechain blocks without moving any stake to the sidechain. Thus sidechain security can be maintained, given an honest stake majority among the entities that have signaled sidechain awareness. Especially in the bootstrapping stage, these main-chain validators are expected to be a large superset of the set of stakeholders that maintain assets in the sidechain.  
+## More information
+For a full description of the theoretical underpinning of the design, refer to the [original white paper](https://eprint.iacr.org/2018/1239.pdf).
+## Contact Input Output
+To get involved, contact IOG through the [commercial contact page](https://iohk.io/en/contact-commercial/).

content/08-cardano-sidechains/01-basics/02-ouroboros-description.mdx

@@ -0,0 +1,45 @@
+---
+title: About Ouroboros BFT
+metaTitle: About Ouroboros BFT
+---
+
+# Ouroboros BFT: A simple Byzantine fault tolerant consensus protocol
+Ouroboros, named after the symbol of infinity, is the backbone of the Cardano ecosystem. Ouroboros BFT is the version that is implemented in Cardano's example EVM sidechain. It is a simple, deterministic protocol for ledger consensus that tolerates Byzantine faults.
+
+## Background 
+So what is a Byzantine fault? To understand that, we have to go back to 1982, to the [Byzantine generals problem](https://www.microsoft.com/en-us/research/uploads/prod/2016/12/The-Byzantine-Generals-Problem.pdf) paper by Leslie Lamport, Robert Shostak, and Marshall Pease. Imagine a number of generals surrounding a city, unable to communicate with each other except by message. The generals must reach consensus on whether to attack or retreat, even if one or more generals is a traitor. This story is easy to grasp, and it is used as an allegory for the situation in a distributed ledger system where the nodes must reach consensus on the contents of the ledger even if one or more of the participating nodes is offline, faulty, or malicious. Such a node can create a **Byzantine fault**. The problem is easy to grasp but hard to solve. That's where Ouroboros comes in.  
+## Description
+This description is based on blogs by Professor Aggelos Kiayias and Kieran Costello.
+### A word on consensus protocols, and why Ouroboros is different
+It's reasonable to assume that anybody new to the space might be confused by the term 'consensus protocol'. Put simply, a consensus protocol is the system of laws and parameters that govern the behavior of distributed ledgers: a ruleset by which each network participant plays.  
+
+There is no single central authority to control a public blockchain. Instead, a consensus protocol is used to allow distributed network participants to agree on the history of the network captured on the blockchain – to reach consensus on what has happened, and continue from a single source of truth.  
+
+That single source of truth provides a single record. This is why blockchains are sometimes referred to as trustless. Instead of requiring participants to trust one another, trust is built into the protocol. Unknown actors may interact and transact with each other without relying on an intermediary to mediate or for there to be a prerequisite exchange of personal data.  
+
+Ouroboros is a proof-of-stake protocol, which is distinct from proof of work. Rather than relying on 'miners' to solve computationally complex equations to create new blocks – and rewarding the first to do so – proof of stake selects participants (in the case of Cardano, stake pools) to create new blocks based on the stake they control in the network.  
+
+Networks using Ouroboros are many times more energy-efficient than those using proof of work, and, through Ouroboros, Cardano is able to achieve unparalleled energy efficiency. The resulting difference in energy use can be analogized to that between a household and a small country: one can be scaled to the mass market; the other cannot.  
+
+Now, let's take a closer look at how the Ouroboros protocol works.  
+
+### Ouroboros Classic
+Starting with Ouroboros, the first implementation of the Ouroboros protocol, published in 2017. This first implementation (referred to as Ouroboros Classic) laid the foundations for the protocol as an energy-efficient rival to proof of work. It introduced the mathematical framework to analyze proof of stake and a novel incentive mechanism to reward participants in a proof-of-stake setting.  
+
+More than this, however, what separated Ouroboros from other blockchain protocols and, 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 and is a critical part of maintaining the protocol's security. Whenever an adversary can predict a behavior, they can exploit it – and though Ouroboros ensures transparency, it prevents coercion. Significantly, Ouroboros was the first blockchain protocol to be developed with this type of rigorous security analysis.  
+
+### How Ouroboros works
+ [The research paper](https://iohk.io/en/research/library/papers/ouroborosa-provably-secure-proof-of-stake-blockchain-protocol/) on Ourorobos gives a comprehensive explanation of how it works. To summarize, Ouroboros divides the blockchain into slots and epochs. In Cardano, each slot lasts for 20 seconds, and each epoch represents approximately five days' worth of slots.  
+
+Central to Ouroboros' design is the recognition that attacks are inevitable. As such, the protocol has tolerance built in 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. In fact, the protocol is guaranteed to be secure so long as more than 51% of the stake is controlled by honest participants (that is, 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 number defines 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.  
+
+### Ouroboros BFT
+Ouroboros BFT (Byzantine Fault Tolerance) is a simple protocol used by Cardano during the Byron reboot, which was the transition of the old Cardano codebase to the new. Ouroboros BFT helped prepare Cardano's network for Shelley's release and, with that, its decentralization. This is the version of Ourorobos that is implemented in the Cardano EVM sidechain. 
+
+Rather than requiring nodes to be online all of the time, Ouroboros BFT assumes a federated network of servers – the blockchain – and synchronous communication between the servers, providing ledger consensus in a simpler and more deterministic manner.  
+
+Additional benefits include instant proof of settlement, transaction settlement at network speed – which means the determiner for transactions is the speed of your network connection to an OBFT node – and instant confirmation in a single round trip of communication. Each of these results in significant performance improvements.  

content/08-cardano-sidechains/01-basics/04-block-explorer.mdx

@@ -0,0 +1,192 @@
+---
+title: 'About block explorer'
+metaTitle: 'About block explorer'
+---
+
+A block explorer allows you to inspect a blockchain to see its blocks and
+transactions.  
+
+This document is based primarily on the
+[Blockscout explorer](https://blockscout.com/), but blockchain explorers
+necessarily use similar terminology and follow a similar pattern in their
+presentation of information.  
+
+When you use a block explorer, it will list fields and their contents. This document will help you understand the meaning of the field names and the
+significance of their contents.
+
+## Glossary
+These are the field names commonly used in block explorers on the example EVM sidechain.
+## General terms
+<dl>
+  <p></p><dt>
+    <strong>Actor</strong>
+  </dt>
+  <dd>
+    Any entity that can make something happen on a blockchain. Actors can
+    include users, wallets, addresses, and network nodes.
+  </dd>
+  <p></p><dt>
+    <strong>Address</strong>
+  </dt>
+  <dd>
+    An address is a location to or from which transactions occur on the
+    blockchain. It is associated with a public key.
+  </dd>
+  <p></p><dt>
+    <strong>Hash function</strong>
+  </dt>
+  <dd>
+    A cryptographic hash function takes a string of variable length and produces
+    a fixed-length string called a <b>hash value</b>. A hash value is easy to
+    calculate, but it is not feasible to derive the input given only the output,
+    and it is not feasible to calculate two inputs that will produce the same
+    hash value. For a canonical definition, see&nbsp; 
+    <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf">
+      this NIST publication.
+    </a>
+    <p>
+      Any change to the input, no matter how small, will result in a very
+      different output. Each block contains the hash of the preceding block so
+      that anyone can check the chain's integrity.
+     </p>
+     </dd>
+</dl>
+
+## Home page
+<dl>
+  <p></p><dt>
+    <strong>Average block time</strong>
+  </dt>
+  <dd>
+    The length of time between adding one block to the blockchain and adding the
+    next block; the time it takes to add a block to the chain. It depends on
+    the slot time of the chain.
+  </dd>
+  <p></p><dt>
+    <strong>Total transactions</strong>
+  </dt>
+  <dd>
+    A transaction is an event on the blockchain, such as a transfer of currency
+    from one address to another. A variable number of transactions can fit in
+    each block.
+    <p>
+     By comparing total transactions with total blocks, you can deduce the
+     average number of transactions per block.
+    </p>
+  </dd>
+  <p></p><dt>
+    <strong>Total blocks</strong>
+  </dt>
+  <dd>
+    One more than the current block height of the chain, which is the latest block
+    number.
+  </dd>
+  <p></p><dt>
+    <strong>Wallet addresses</strong>
+  </dt>
+  <dd>
+    The number of wallet addresses used in the blockchain so far.
+    <p>
+    A wallet address is the source or destination of a transfer. 
+     In the Ethereum account model, a wallet has exactly one address.
+    </p>
+  </dd>
+</dl>
+
+## Blocks
+<dl>
+  <p></p><dt>
+    <strong>Block height</strong>
+  </dt>
+  <dd>
+    The number of this block. It is one less than the number of valid blocks
+    added to the blockchain to this point. (The first block is block 0). Invalid or ignored
+    blocks are not counted.
+  </dd>
+  <p></p><dt>
+    <strong>Timestamp </strong>
+  </dt>
+  <dd>The time the block was added to the chain.</dd>
+  <p></p><dt>
+    <strong>Transactions</strong>
+  </dt>
+  <dd>The number of transactions included in the block.</dd>
+  <p></p><dt>
+    <strong>Validator</strong>
+  </dt>
+  <dd>The address of the actor that added this block to the chain.</dd>
+  <p></p><dt>
+    <strong>Size</strong>
+  </dt>
+  <dd>The length of the block in bytes.</dd>
+  <p></p><dt>
+    <strong>Hash</strong>
+  </dt>
+  <dd>
+    The hash value of this block. See the definition of 'hash function' above.
+  </dd>
+  <p></p><dt>
+    <strong>Parent hash</strong>
+  </dt>
+  <dd>The hash value of the preceding block.</dd>
+  <p></p><dt>
+    <strong>Gas used</strong>
+  </dt>
+  <dd>
+    Gas is paid to validators to compensate them for the resources used to process a
+    transaction. The price of gas varies with supply and demand.
+  </dd>
+  <p></p><dt>
+    <strong>Gas limit</strong>
+  </dt>
+  <dd>
+    The maximum amount of gas the actor that initiated the transaction is
+    willing to pay.
+  </dd>
+  <p></p><dt>
+    <strong>Validator Reward</strong>
+  </dt>
+  <dd>
+    The number of coins awarded to the validator of this block. The coins are newly
+    minted; they do not come from transaction fees.
+  </dd>
+</dl>
+
+## Transactions
+<dl>
+  <p></p><dt>
+    <strong>Transaction</strong>
+  </dt>
+  <dd>
+    The block explorer will show a transfer of currency as a Transaction.
+    <p>
+    The formal definition is 
+        <i> 'A piece of data, signed by an External Actor. It represents either a
+        Message or a new Autonomous Object. Transactions are recorded into each
+        block of the blockchain.' </i>
+      (From the Yellow Paper.)
+      </p>
+      </dd>
+  <p></p><dt>
+    <strong>Contract call</strong>
+  </dt>
+  <dd>
+    A contract call is a special case of a transaction; the destination is a
+    smart contract rather than an end user. A smart contract has been sent to
+    the network and recorded on the blockchain.
+  </dd>
+  <p></p><dt>
+    <strong>Call</strong>
+  </dt>
+  <dd>
+    Note that if a node uses the web3.js call method web3.eth.call, it will not
+    show in a block explorer because it is a local action; the network is not
+    informed about it and it will not affect the blockchain. The underlying
+    JSON-RPC is eth_call.
+    <p>
+    This technique is used in a 'dry run' of a smart contract. When it works
+    successfully, the smart contract can be sent to the blockchain using
+    web3.eth.sendSignedTransaction.
+    </p>
+  </dd>
+</dl>

content/08-cardano-sidechains/02-sidechain-toolkit.mdx

@@ -0,0 +1,6 @@
+---
+title: Sidechain toolkit
+metaTitle: Sidechain toolkit
+---
+
+<!-- heading no content -->