Blochcain Network
Blockchain Structure of FRQTAL Subnet
The FRQTAL Subnet is a blockchain built on Avalanche, a cutting-edge layer 1 blockchain network. Here's an overview of the blockchain structure and how it utilizes Avalanche's unique features:
Choice of Avalanche Subnet for Usability: FRQTAL has chosen to build its blockchain as a subnet of Avalanche due to the network's exceptional usability and advanced consensus mechanism. Avalanche's capabilities enable FRQTAL to create a highly efficient and scalable blockchain ecosystem.
Based on Avalanche Consensus: The FRQTAL Subnet utilizes Avalanche's blazingly fast consensus mechanism. This consensus ensures rapid transaction finality and low latency. In under 2 seconds, transactions are effectively processed and verified, ensuring speedy and efficient blockchain operations.
Built for Scalability: Developers within the FRQTAL ecosystem can create application-specific blockchains with complex rulesets. They have the flexibility to build on existing private or public Subnets using their preferred programming language. Avalanche's scalability ensures that the network can accommodate thousands of concurrent validators without compromising performance, making it an ideal choice for scaling internet systems.
Energy-Efficient Design: The FRQTAL Subnet running on Avalanche is exceptionally energy-efficient. It can operate on consumer-grade hardware and consumes significantly less energy compared to many other blockchain networks. The energy consumption is equivalent to that of only 46 US households, making it a sustainable and eco-friendly solution.
Advanced Security and Customization: The Avalanche consensus provides robust security, which scales effectively to maintain the integrity of the network, even with a large number of validators. FRQTAL Subnet offers both permissionless and permissioned custom blockchains, allowing the inclusion of custom rulesets tailored to comply with legal and jurisdictional requirements.
Working with a Validation Chain: The FRQTAL Subnet operates with a validation chain that consists of nodes specific to the FRQTAL protocol. These nodes collaborate with the primary Avalanche validation network to execute exchanges and validate transactions securely and efficiently.
By leveraging Avalanche's innovative features and scalability, the FRQTAL Subnet can provide a highly secure, efficient, and customizable blockchain ecosystem. It ensures fast and reliable transaction processing, making it an ideal platform for various applications and use cases within the FRQTAL network.
Intuition
First, let's develop some intuition about the protocol. Imagine a room full of people trying to agree on what to get for lunch. Suppose it's a binary choice between pizza and barbecue. Some people might initially prefer pizza while others initially prefer barbecue. Ultimately, though, everyone's goal is to achieve consensus.
Everyone asks a random subset of the people in the room what their lunch preference is. If more than half say pizza, the person thinks, "OK, looks like things are leaning toward pizza. I prefer pizza now." That is, they adopt the preference of the majority. Similarly, if a majority say barbecue, the person adopts barbecue as their preference.
Everyone repeats this process. Each round, more and more people have the same preference. This is because the more people that prefer an option, the more likely someone is to receive a majority reply and adopt that option as their preference. After enough rounds, they reach consensus and decide on one option, which everyone prefers.
Snowball
The intuition above outlines the Snowball Algorithm, which is a building block of Avalanche consensus. Let's review the Snowball algorithm.
Parameters
n: number of participants
k (sample size): between 1 and n
α (quorum size): between 1 and k
β (decision threshold): >= 1
Algorithm
Algorithm Explained
Everyone has an initial preference for pizza or barbecue. Until someone has decided, they query k people (the sample size) and ask them what they prefer. If α or more people give the same response, that response is adopted as the new preference. α is called the quorum size. If the new preference is the same as the old preference, the consecutiveSuccesses counter is incremented. If the new preference is different then the old preference, the consecutiveSuccesses counter is set to 1. If no response gets a quorum (an α majority of the same response) then the consecutiveSuccesses counter is set to 0.
Everyone repeats this until they get a quorum for the same response β times in a row. If one person decides pizza, then every other person following the protocol will eventually also decide on pizza.
Random changes in preference, caused by random sampling, cause a network preference for one choice, which begets more network preference for that choice until it becomes irreversible and then the nodes can decide.
In our example, there is a binary choice between pizza or barbecue, but Snowball can be adapted to achieve consensus on decisions with many possible choices.
The liveness and safety thresholds are parameterizable. As the quorum size, α, increases, the safety threshold increases, and the liveness threshold decreases. This means the network can tolerate more byzantine (deliberately incorrect, malicious) nodes and remain safe, meaning all nodes will eventually agree whether something is accepted or rejected. The liveness threshold is the number of malicious participants that can be tolerated before the protocol is unable to make progress.
These values, which are constants, are quite small on the Avalanche Network. The sample size, k, is 20. So when a node asks a group of nodes their opinion, it only queries 20 nodes out of the whole network. The quorum size, α, is 14. So if 14 or more nodes give the same response, that response is adopted as the querying node's preference. The decision threshold, β, is 20. A node decides on choice after receiving 20 consecutive quorum (α majority) responses.
Snowball is very scalable as the number of nodes on the network, n, increases. Regardless of the number of participants in the network, the number of consensus messages sent remains the same because in a given query, a node only queries 20 nodes, even if there are thousands of nodes in the network.
Everything discussed to this point is how Avalanche is described in the Avalanche white-paper. The implementation of the Avalanche consensus protocol by Ava Labs (namely in AvalancheGo) has some optimizations for latency and throughput.
Blocks
A block is a fundamental component that forms the structure of a blockchain. It serves as a container or data structure that holds a collection of transactions or other relevant information. Each block is cryptographically linked to the previous block, creating a chain of blocks, hence the term "blockchain."
In addition to storing a reference of its parent, a block contains a set of transactions. These transactions can represent various types of information, such as financial transactions, smart contract operations, or data storage requests.
If a node receives a vote for a block, it also counts as a vote for all of the block's ancestors (its parent, the parents' parent, etc.).
Finality
Avalanche consensus is probabilistically safe up to a safety threshold. That is, the probability that a correct node accepts a transaction that another correct node rejects can be made arbitrarily low by adjusting system parameters. In Nakamoto consensus protocol (as used in Bitcoin and Ethereum, for example), a block may be included in the chain but then be removed and not end up in the canonical chain. This means waiting an hour for transaction settlement. In Avalanche, acceptance/rejection are final and irreversible and only take a few seconds.
Optimizations
It's not safe for nodes to just ask, "Do you prefer this block?" when they query validators. In Ava Labs' implementation, during a query a node asks, "Given that this block exists, which block do you prefer?" Instead of getting back a binary yes/no, the node receives the other node's preferred block.
Nodes don't only query upon hearing of a new block; they repeatedly query other nodes until there are no blocks processing.
Nodes may not need to wait until they get all k query responses before registering the outcome of a poll. If a block has already received alpha votes, then there's no need to wait for the rest of the responses.
Validators
If it were free to become a validator on the Avalanche network, that would be problematic because a malicious actor could start many, many nodes which would get queried very frequently. The malicious actor could make the node act badly and cause a safety or liveness failure. The validators, the nodes which are queried as part of consensus, have influence over the network. They have to pay for that influence with real-world value in order to prevent this kind of ballot stuffing. This idea of using real-world value to buy influence over the network is called Proof of Stake.
To become a validator, a node must bond (stake) something valuable (AVAX). The more AVAX a node bonds, the more often that node is queried by other nodes. When a node samples the network it's not uniformly random. Rather, it's weighted by stake amount. Nodes are incentivized to be validators because they get a reward if, while they validate, they're sufficiently correct and responsive.
Avalanche doesn't have slashing. If a node doesn't behave well while validating, such as giving incorrect responses or perhaps not responding at all, its stake is still returned in whole, but with no reward. As long as a sufficient portion of the bonded AVAX is held by correct nodes, then the network is safe, and is live for virtuous transactions.
Big Ideas
Two big ideas in Avalanche are subsampling and transitive voting.
Subsampling has low message overhead. It doesn't matter if there are twenty validators or two thousand validators; the number of consensus messages a node sends during a query remains constant.
Transitive voting, where a vote for a block is a vote for all its ancestors, helps with transaction throughput. Each vote is actually many votes in one.
Loose Ends
Transactions are created by users which call an API on an AvalancheGo full node or create them using a library such as AvalancheJS.
Other Observations
Conflicting transactions are not guaranteed to be live. That's not really a problem because if you want your transaction to be live then you should not issue a conflicting transaction.
Snowman is the name of Ava Labs' implementation of the Avalanche consensus protocol for linear chains.
If there are no undecided transactions, the Avalanche consensus protocol quiesce. That is, it does nothing if there is no work to be done. This makes Avalanche more sustainable than Proof-of-work where nodes need to constantly do work.
Avalanche has no leader. Any node can propose a transaction and any node that has staked AVAX can vote on every transaction, which makes the network more robust and decentralized.
Avalanche Consensus guarantees that if any honest validator accepts a transaction, all honest validators will come to the same conclusion.
Last updated
