Avalanche features 3 integrated blockchains: Exchange Chain (X-Chain), Platform Chain (P-Chain), and Contract Chain (C-Chain). All 3 blockchains are validated and protected by the mainnet. The mainnet is a special subnet, and all members of all custom subnets must also be members of the mainnet by staking at least 2000 AVAX.
Guía de Staking | AvalancheSnapshot de la Blockchain | AvalanchePresentación Become A Validator | AvalancheGuía Full Node | Avalanche
Avalanche documentation available at SenseiNode
General Information about Avalanche
What are Subnets?
A subnet, or subnetwork, is a dynamic set of validators that work together to reach a consensus on the state of a set of blockchains. Each blockchain is validated by exactly one subnet. A subnet can validate many blockchains. A node can be a member of many subnets.
A subnet manages its own membership and may require its constituent validators to have certain properties. This is very useful, and we explore its ramifications in more depth below:
Avalanche's subnet architecture makes regulatory compliance manageable. As mentioned above, a subnet may require validators to meet a set of requirements.
Some examples of requirements include:
- Validators must be located in a certain country
- Validators must pass KYC/AML checks
- Validators must have a certain license
(To be very clear, the examples above are just that: examples. These requirements do not apply to the Avalanche mainnet.)
You can create a subnet where only certain predefined validators can join and create a private subnet where the content of the blockchains would be visible only to these validators. This is ideal for organizations interested in keeping their information private. See here for more information.
Separation of Concern
In a heterogeneous network of blockchains, some validators will not want to validate certain blockchains because they simply have no interest in those blockchains. The subnet model allows validators to only care about the blockchains they care about. This reduces the load on validators.
Application Specific Requirements
Different blockchain-based applications may require validators to have certain properties. Suppose there is an application that requires large amounts of RAM or CPU power. A subnet might require validators to meet certain hardware requirements so that the application does not experience poor performance due to slow validators.
A virtual machine (VM) defines the application level logic of a blockchain. In technical terms, it specifies the state of the blockchain, the state transition function, the transactions, and the API through which users can interact with the blockchain. Each blockchain in Avalanche is an instance of a VM.
When you write a VM, you don't need to worry about lower-level logic like networking, consensus, and blockchain structure. Avalanche does this behind the scenes so you can focus on what you'd like to build.
Think of a virtual machine as a blueprint for a blockchain; you can use the same VM to create many blockchains, each of which follows the same set of rules but is logically independent of other blockchains.
Why virtual machines?
In the beginning, blockchain networks had a virtual machine (VM) with a static and predefined set of functionality. This rigid, monolithic design limited the blockchain-based applications that could run on such networks.
People who wanted custom decentralized applications had to create their own completely new blockchain network from scratch. Doing so took a great deal of time and effort, offered limited security, and generally resulted in a brittle, custom blockchain that never really took off.
Ethereum took a step towards solving this problem with smart contracts. Developers didn't need to worry about networks and consensus, but building decentralized apps was still difficult. The Ethereum virtual machine has poor performance and places restrictions on smart contract developers. Solidity and the few other languages for writing Ethereum smart contracts are unfamiliar to most programmers.
Avalanche VM (AVM) makes it easy to define a decentralized blockchain-based application. Instead of new, limited languages like Solidity, developers can write virtual machines in Go (other languages will be supported in the future).