Parachain & Parathread
Last updated
Last updated
A parachain is an application-specific data structure that is globally coherent and can be validated by the validators of the Relay Chain. They take their name from the concept of parallelized chains that run parallel to the Relay Chain. Most commonly, a parachain will take the form of a blockchain, but there is no specific need for them to be actual blockchains.
Due to their parallel nature, they can parallelize transaction processing and achieve scalability of the Cherry Network protocol. They inherit the security of the entire network and can communicate with other parachains through the XCM format.
Parachains are maintained by a network maintainer known as a collator. The role of the collator node is to maintain a full node of the parachain, retain all necessary information about the parachain, and produce new block candidates to pass to the Relay Chain validators for verification and inclusion in the shared state of Cherry Network. The incentivization of a collator node is an implementation detail of the parachain. They are not required to be staked on the Relay Chain or own the native token unless stipulated by the parachain implementation.
Like other blockchains, parachains are deterministic state machines. Each parachain has a state, executes a batch of transactions grouped into a block, and achieves a new state. Joe Petrowski provided in this article a good analogy of a state with a light switch that can be either on or off, which is one of the simplest examples of how a state machine functions. Each parachain has its own state, and the Relay Chain links all those states into one state, i.e. a state of states. A multi-chain network like Cherry can be viewed like one computer's state with many light switches, where a state transition function is the logic to decide which switches should be toggled. Parachains have their own transition rule, separate economies, governance mechanisms, and users.
A parachain's state is stored in a Merkle tree. Merkle trees have the convenient property that if some values within the tree change, this will be reflected in the Merkle root (in this case, the state root). One can verify the change by only looking at the new values and the paths that are affected within the tree.
The Cherry Host requires that the state transitions performed on parachains be specified as a Wasm executable. Proofs of new state transitions that occur on a parachain must be validated against the registered state transition function (STF) that is stored on the Relay Chain by the validators before Cherry acknowledges a state transition has occurred on a parachain. The key constraint regarding the logic of a parachain is that it must be verifiable by the Relay Chain validators. Verification most commonly takes the form of a bundled proof of a state transition is known as a Proof-of-Verification (PoV) block, which is submitted for checking to the validators from one or more parachain collators.
Parachains are a solution to two fundamental problems in blockchains:
Scalability: Having one blockchain for many purposes makes it difficult to scale as future implementations and upgrades will likely advantage some purposes and disadvantage others. Conversely, having different blockchains will allow them to implement features without affecting other chains.
Flexibility: It is reasonable to state a blockchain will either be really good at solving one problem or not so good at trying to solve many problems. A blockchain specializing in solving a specific problem has more leverage toward itself and its users. Parachains are purpose-built blockchains are highly specialized and can take advantage of each other through cooperation.
Shared security, sometimes referred as pooled security, is one of the unique value propositions for chains considering becoming a parachain and joining the Cherry Network. On a high level, shared security means that all parachains that are connected to the Cherry Relay Chain by leasing a parachain slot will benefit from the economic security provided by the Relay Chain validators.
The notion of shared security is different from inter-chain protocols that build on an architecture of bridges. For bridge protocols, each chain is considered sovereign and must maintain its own validator set and economic security. One concern in these protocols is the point of scalability of security. For example, one suggestion to scale blockchains is that of scale by altcoins, which suggests that transaction volumes will filter down to lower market cap altcoins as the bigger ones fill their blocks. A major flaw in this idea is that the lower market cap coins will have less economic security attached and be easier to attack. A real-life example of a 51% attack occurred recently ( Ethereum Classic attack on January 10, 2019 ), in which an unknown attacker double spent 219_500 ETC (~1.1 million USD). This was followed by two more 51% attacks on ETC.
Cherry overcomes security scalability concerns since it gravitates all the economic incentives to the Relay Chain and allows the parachains to tap into stronger guarantees at genesis. Sovereign chains must expend much more effort to grow the value of their coin so that it is sufficiently secure against well-funded attackers.
Let's compare the standard sovereign security model that exists on current proof-of-work (PoW) chains to that of the shared security of Cherry. Chains secured by their security models, like Bitcoin, Zcash, and their derivatives, must bootstrap their independent network of miners and maintain a competitive portion of honest hashing power. Since mining is becoming a larger industry that increasingly centralizes key players, it is becoming more real that a single actor may control enough hash power to attack a chain.
This means that smaller chains that cannot maintain a secure amount of hash power on their networks could potentially be attacked by a large mining cartel at the simple whim of redirecting its hash power away from Bitcoin and toward a new and less secure chain. 51% attacks are viable today with attacks having been reported on Ethereum Classic (see above), Verge, Bitcoin Gold, and other cryptocurrencies.
On Cherry, this disparity between chain security will not be present. When a parachain connects to Cherry, the relay chain validators become the securers of that parachain's state transitions. The parachain will only have the overhead of running a few collator nodes to keep the validators informed with the latest state transitions and proofs/witness. Validators will then check these for the parachains to which they are assigned. In this way, new parachains instantly benefit from the overall security of Cherry, even if they have just been launched.
Parachains may have their economies with their native tokens. Schemes such as Proof-of-Stake are usually used to select the validator set to handle validation and finalization; parachains will not be required to do either of those things. However, since Cherry is not overly particular about what the parachain can implement, it may be the choice of the parachain to implement a staking token, but it's not generally necessary.
Collators may be incentivized through the inflation of a native parachain token. There may be other ways to incentivize the collator nodes that do not involve inflating the native parachain token.
Transaction fees in a native parachain token can also be an implementation choice of parachains. Cherry makes no hard and fast rules for how the parachains decide on the original validity of transactions. For example, a parachain may be implemented so that transactions must pay a minimum fee to collators to be valid. The Relay Chain will enforce this validity. Similarly, a parachain could not include that in their implementation, and Cherry would still enforce its validity.
Parachains are not required to have their token. If they do, it is up to the parachain to make the economic case for their token, not Cherry.
While Cherry enables crosschain functionality amongst the parachains, it necessitates that there is some latency between the dispatch of a message from one parachain until the destination parachain receives the message. In the optimistic scenario, the latency for this message should be at least two blocks - one block for the message to be dispatched and one block for the receiving parachain to process and produce a block that acts upon the message. However, in some cases, we may see that the latency for messages is higher if many messages are in queue to be processed or if no nodes are running both parachain networks that can quickly gossip the message across the networks.
Due to the necessary latency in sending crosschain messages, some parachains plan to become hubs for an entire industry. For example, a parachain project Acala is planning to become a hub for decentralized finance (DeFi) applications. Many DeFi applications take advantage of a property known as composability which means that functions of one application can be synergistically composed with others to create new applications. One example of this includes flash loans, which borrow funds to execute some on-chain logic as long as the loan is repaid at the end of the transaction.
An issue with crosschain latency means that composability property weakens among parachains compared to a single blockchain. This implication is common to all sharded blockchain designs, including Polkadot, Eth2.0, and others. The solution to this is the introduction of parachain hubs, which maintain the stronger property of single block composability.
Cherry Network supports a limited number of parachains, currently estimated to be about 100. As the number of slots is limited, there are several ways to allocate them:
Governance granted parachains, or "system parachains"
Auction granted parachains
System parachains are allocated by Cherry on-chain governance and are part of the network's protocol, such as bridges to other networks or chains. These typically do not have an economic model and help remove transactions from the Relay Chain, allowing for more efficient parachain processing.
Auction granted parachains are granted in a permissionless auction. Parachain teams can either bid with their own DOT tokens, or source them from the community using the crowdloan functionality.
Parathreads have the same API as parachains, but are scheduled for execution on a pay-as-you-go basis with an auction for each block.
When a parachain wins an auction, the tokens it bids get reserved until the lease's end. Reserved balances are non-transferrable and cannot be used for staking. At the end of the lease, the tokens are unreserved. Parachains that have not secured a new lease to extend their slot will automatically become parathreads.
System parachains are parachains that use execution cores allocated by the network's governance. These chains remove transactions from the Relay Chain, allowing network validators to allocate resources to validating parachains. System chains are using their scaling technology to host themselves.
See the Polkadot blog article, this Polkadot Forum thread, and the system parachains page for more information.
Note that we still have to see the true potential of parachains and what it is listed below are just a few examples.
Encrypted Consortium Chains: These are possibly private chains that do not leak any information to the public but still can be interacted with trustlessly due to the nature of the XCMP protocol.
High-Frequency Chains: These chains can compute many transactions in a short amount of time by taking certain trade-offs or making optimizations.
Privacy Chains: These chains do not leak any information to the public through novel cryptography.
Smart Contract Chains: These chains can have additional logic implemented through the deployment of code known as smart contracts.
Cherry includes a blockchain called a relay chain. A blockchain is a Directed Acyclic Graph (DAG) of state transitions, where every added block can be viewed as the head of the chain or fork with a cumulative state. All paths through the DAG terminate at the Genesis Block. A blockchain is a tree, as each block can have only one parent.
A blockchain network is made of nodes that have a view of many forks of the chain and must decide which fork to follow. To construct the parachain host we need to answer two categories of questions addressed by two different components:
What is the state transition function of the blockchain? This is handled by the Runtime, which defines the state transition logic of the chain. The Runtime logic is divided into:
Modules encapsulate particular behavior of the protocol and consist of:
Storage
Routines are invoked by entry points and other modules upon block initialization or closing. Routines can alter the storage of a module.
The entry point defines how new information is introduced to a module and can limit the origin from which they are called (user, root, parachain).
API provides means for the node-side behavior to extract meaningful information from the state of a single fork.
INFO
The Cherry Parachain Host Implementers' Guide provides details about Runtime Architecture and Runtime API.
Knowing various forks of the blockchain, what behaviors should a node take? What information should a node extract from the state of which forks, and how should that information be used? This is handled by the Node-side behavior, which defines all activities a node undertakes given its view of the blockchain. The node-side behavior can be divided into two categories:
Networking behaviors, relate to how information is distributed between nodes but not how the information is used afterward.
Core behaviors, relate to internal work that a specific node does. Such behavior cares about that information is distributed and received, but not how these two are achieved.
These two categories often interact, but they can be heavily abstracted from each other. The node-side behavior is split into various subsystems, which perform a particular category of work. Subsystems can communicate with each other through an Overseer that prevents race conditions.
INFO
The Cherry Parachain Host Implementers' Guide provides details about node architecture the main subsystems:
The Runtime and Node-side behavior are dependent on each other. The Runtime depends on Node-side behavior to author blocks, and to include extrinsics which trigger the correct entry points. The Node-side behavior relies on the Runtime APIs to extract information necessary to determine which action to take.
Polkadot: The Parachain - Blog post by Polkadot co-founder Rob Habermeier who introduced parachains in 2017 as "a simpler form of blockchain, which attaches to the security provided by a Relay Chain rather than providing its own. The Relay Chain provides security to attached parachains, but also provides a guarantee of secure message-passing between them."
The Path of a Parachain Block - A technical walk-through of how parachains interact with the Relay Chain.
