Tl;dr
The Avalanche smart contract platform was born out of the avalanche consensus mechanism.
Avalanche has been one of the biggest success stories of the past year and is a top alternative layer 1 to Ethereum
Avalanche subnets are a differentiating factor for avalanche and allow users to spin up application specific custom. blockchains that utilize the validation and consensus technology that powers Avalanche
For our use case, application specific blockchains could be quite potent.
If EVM compatibility is coming to ZKRs in the next 6 months, does anything else stand a chance?
Executive Summary
Avalanche has taken the DeFi world by storm in 2021 by providing an EVM compatible ecosystem with very cheap fees and almost instant finality. Subnets are another Avalanche innovation that are now starting to see life. A subnet is a custom blockchain that is validated by Avalanche. This subnet is custom in the sense that we can set all of the network parameters, such as validator sets, gas costs, and gas token which really opens up the design space. This silo’d nature is not the best thing for general DeFi composability, but in the case of building a derivatives exchange, where performance and cost are primary concerns, this architecture could be a game changer and we will explore all of this below.
Avalanche High Level Overview Avalanche is a new smart contract enabled blockchain. Avalanche features three built-in blockchains.
Exchange Chain (X-Chain) Platform Chain (P-Chain) Contract Chain (C-chain)
All three are validated and secured by the Primary Network. The Primary Network is a special subnet and all members of all custom subnets must also be a member of the Primary Network by staking at least 2,000 AVAX tokens.
Reference the links in the above section for specifics about the 3 built in blockchains, but in a nutshell:
The X-Chain was the first iteration of Avalanche and runs the Avalanche Virtual Machine and Avalanche consensus protocol.
The P-Chain is the metadata blockchain on Avalanche that coordinates validators, keeps track of subnets, and enables the creation of new subnets. This chain runs the snowman consensus protocol.
The C-Chain is an instance of the Ethereum Virtual Machine powered by Avalanche. Smart contracts can be created on this chain. This is where all of the DeFi activity takes place on Avalanche. This chain runs the snowman consensus protocol.
Benefits of this architecture
Instead of a single monolithic blockchain where all computation and validation are performed, Avalanche’s core, or built-in, chains separate these concerns.
The heart of the consensus protocol on Avalanche is based on a 2018 research paper called “Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family for Cryptocurrencies”. Less than a day later, Emin Gün Sirer (at that time a professor of computer science at Cornell and now the founder and CEO of Ava Labs) reacted to this research on twitter. In short order, he founded Ava Labs and one year later, in collaboration with Team Rocket, published a revised version of the research.
In the 45 year history of distributed computing there have been three approaches to the consensus problem, Classical, Nakamoto, and Avalanche. You can read more here but for the scope of this report, it is important to know that the Avalanche consensus protocol, originally defined in that 2018 research paper, seeks to combine the benefits of Classical and the decentralization of Nakamoto into one protocol.
Instead of a validator checking with all other validators that a block is valid, Avalanche consensus uses sampling. In a given round, each validator selects K nodes in a validator set to query their decision and if the majority of the nodes differ from the node performing the query, the querying node changes its decision to reflect the majority of the nodes it sampled.
This is happening across every validator in the set in parallel, and very quickly all nodes arrive at the same decision. There is a more in depth explanation and illustration here. This novel mechanism is how irreversible finality is reached so quickly in the Avalanche consensus mechanism.
In addition to this, other improvements are made on Nakamoto such as low energy consumption. Instead of miners or validators constantly working, when there is no work to do, the system quiesces, or waits in a low energy consumption state, and listens for work. The documentation goes into greater detail, but the moral of the story is that Ava Labs took the Avalanche consensus protocol and applied it to create the smart contract chain Avalanche.
Key Performance Metrics and attributes
Subnets
One major differentiation between Avalanche and other smart contract platforms is the flexibility offered in the form of subnets. According to the docs, subnets are dynamic sets of validators working together to achieve consensus on the state of a set of blockchains. Each blockchain is validated by exactly one subnet while a subnet can validate many blockchains. A node may be a member of many subnets. A subnet manages membership of its nodes and this can be very beneficial depending on the underlying use case.
Attributes/ Performance
Eliminates the risk of your dApp becoming too expensive due to network congestion caused by other applications.
Customization
Modify every parameter of your blockchain, we can choose the VM, the cost of transactions, the token used to pay for transactions, and other features.
Compliance
Set requirements for validators, such as:
Separation of concerns The subnet model allows validators to only concern themselves with the blockchains that they care about and this reduces the burden on all validators.
Application Specific Requirements Application specific blockchains by definition will have different use cases. These use cases can drive validator requirements. Some applications may require large amounts or RAM or CPU power and your subnet could set requirements for validators to work on it.
Editorial Opinion
Avalanche has been increasing in adoption in the past year. The cost of using Ethereum has been the main catalyst of this growth. Avalanche isn't simply a fork of Geth like BSC is and they have engineered some novel technologies in the form of their consensus engines and subnets. We should think about this by taking a step back and asking ourselves this question: If Ethereum was cheap to use, would Avalanche exist? Or would Avalanche be relevant? This question is hard to answer since Ethereum is expensive and the point in the future when it is not is impossible to predict. The security guarantees and decentralization of Ethereum are superior, but the market has spoken and at the end of the day, people want to participate in DeFi at the expense of supreme decentralization and security.
It is my opinion that when zero knoewldge ethereum rollups get EVM compatibility for general smart contract execution that alternative L1s and optimistic rollups will have three choices.
Those are my opinions, but they are based on the scenario where all dApps can offer extremely cheap transactions that actually get cheaper with congestion & offer immediate L1 security… and why would any user or developer pick anything other than this?
I think this is 3-12 months away and in that timespan these alternative layer 1s and optimistic L2s must create whatever moat they possibly can.
The idea of Avalanche subnets are in this spirit. A subnet would effectively allow us to create a custom public application specific blockchain where consensus is provided by Avalanche validators and their novel consensus engine. This is certainly an intriguing option with several immediate benefits and potential pitfalls.
Since we could make our token the gas token, we could instantiate an immediate use case for it as well as buy pressure on it.
We could tweak the parameters of the blockchain for extremely cheap transactions, paid in our token, that we could then abstract away from the user by covering the transaction costs for them and give them a gasless off chain CLOB experience a la dYdX.
I think that a highly performant devivitives exchange is one of the best use cases for an application specific blockchain. General composability is not a big concern and vastly trumped by the performance and user experience we could provide.
The main problems I see are
Getting validator support Getting robust chainlink services on to a subnet The rise of EVM compatible ZK scaling solutions on Ethereum.
While it is possible, all things being equal, we could just pivot to an EVM compatible ZK solution when they are available, it is not necessarily practical. Since our users base, liquidity, and state root would be on our subnet.
If our product launch is still 3 - 9 months out, why would we bet on anything other than ZKevm?
If we spend the resources engineering a subnet or any other solution and we believe that zkEVM is around the corner and that it will eat everything, then it would make even more sense to ride that wave and be the first well engineered and polished decentralized derivatives exchange to launch.
There is certainly no hard date on when this will be possible, but it's expected by Q2 2022
There is also uncertainty on subnets, only now in February 2022 are these starting to get deployed and to this tpoint, no major protocol has deployed their own subnet.
There are a lot of ways to skin this cat and we should keep a very close eye on these two options for the next 90 days.
/blog/arweave-decentralized-database-research/