🤓FAQ
A learning resource 📕
How are the validator sets authenticated?
The validator sets in Avalanche are authenticated using a threshold of signatures from a randomly chosen subset of validators. A block is verified when two-thirds of these selected validators have signed it. To obtain a specific validator set and its associated proof for the C-Chain, the information stored in the block header, you can use the API provided in the official AVAX docs. The IBC integration between the Avalanche network and a different chain, like Cosmos, uses a Landslide VM that tracks validator set changes from the Avalanche P-chain.
The VM is responsible for processing the incoming validator set changes from the Avalanche P-chain and updating the validator set of the connected subnet accordingly. This would enable the subnet to stay synchronized with the latest validator set of the Avalanche network and ensure secure and consistent transactions.
Additionally, we include a client certificate or acceptance proof, such as a BLS signature, for the parent block in the child block. This ensures that the child block is only accepted if the parent block is accepted, creating a trust chain that maintains the transaction history's integrity.
The overall idea is that chains use a VM on Landslide (CosmWasm, EVM, XCM) to connect the Avalanche network and a different chain, track the validator set changes, and ensure secure and consistent transactions between the two chains.
How is a Cosmos dApp more decentralized on Avax than it is on native Cosmos?
Check the docs. 🤯
See the original Cosmos whitepaper here. "Unlike Bitcoin or other proof-of-work blockchains, a Tendermint blockchain gets slower with more validators due to the increased communication complexity. Fortunately, we can support enough validators to make for a robust globally distributed blockchain with very fast transaction confirmation times, and, as bandwidth, storage, and parallel compute capacity increases, we will be able to support more validators in the future.
On genesis day, the maximum number of validators will be set to 100, and this number will increase at a rate of 13% for 10 years, and settle at 300 validators."
See the Avalanche whitepaper here.
"A core feature of the Snow family is its ability to scale without incurring fundamental tradeoffs. Snow protocols can scale to tens of thousands or millions of nodes, without delegation to subsets of validators. These protocols enjoy the best-in-class system decentralization, allowing every node to fully validate. First-hand continuous participation has deep implications for the security of the system. In almost every proof-of-stake protocol that attempts to scale to a large participant set, the typical mode of operation is to enable scaling by delegating validation to a subcommittee. Naturally, this implies that the security of the system is now precisely as high as the corruption cost of the subcommittee. Subcommittees are furthermore subject to cartel formation."
How is it possible to migrate liquidity from a Cosmos dApp to Avalanche?
Check out this guide here which explains how Cosmos dApps deploy Landslide outposts to Avalanche. Each Cosmos dApp has to effectively deploy its entire software stack to the Avalanhe network via a subnet. Avalanche X and C chains do not allow for custom VMs; they can only be connected via subnet communication.
A connection to a Cosmos dApp is only secured by IBC light client verification.
The Cosmos dApp (including its VM) will be redeployed on its original VM with a new Avalanche consensus algoritm.
If a Cosmos dApp is deployed to Landslide Network, does it have a more decentralized validator set?
YES. 🤯
There can be more decentralization of validators on Avalanche, as there is no hard cap on the number of validators as there is with Tendermint. Avalanche currently has 1,238 validators, which can scale infinitely, and all of these validators can validate on the Landslide subnet. This means that an existing Cosmos zone can have an unlimited number of validators on the Landslide subnet, which can increase the decentralization of the network. The Avalanche consensus protocol is probabilistic, as described in the Avalanche documentation, operates differently from other consensus mechanisms like those used in Ethereum (Nakamoto) or Cosmos (Tendermint). Here are some key points that help answer your questions:
1.) Uncapped Validator Set: Avalanche consensus operates through repeated sub-sampled voting. When a node is determining whether a transaction should be accepted, it asks a small, random subset of validator nodes for their preference. This process is repeated until the validators queried reply with the same answer for a sufficient number of consecutive rounds. This approach allows the validator set in Avalanche to expand infinitely, as the consensus process does not require communication with all validators, only a small, randomly chosen subset.
2.) Fast Finality: Avalanche consensus provides sub-second, immutable finality, ensuring that transactions are quickly confirmed and irreversible. This is achieved without needing to limit the number of validators, as the consensus process is not dependent on the size of the validator set.
3.) Security Guarantees: Avalanche consensus is designed to resist various attacks, including Sybil attacks, distributed denial-of-service (DDoS) attacks, and collusion attacks. Its probabilistic nature (rather than the deterministic nature of all Tendermint chains) ensures that the consensus outcome converges to the desired state, even when the network is under attack.
4.) Proven Scalability: The scalability of the Avalanche consensus protocol is not just theoretical. The protocol has been implemented and tested live in the Avalanche network, demonstrating its ability to handle a large number of validators (currently 1,238) without compromising on performance or security.
Do all Rust contracts of a Cosmos dApp need to be redeployed onto the Landslide subnet in order to benefit from decreased time to finality and transactions per second?
Yes, in order to take advantage of the higher transactions per second and faster finality provided by the Landslide network, the existing Rust contracts of a Cosmos dApp would need to be redeployed onto the Landslide subnet using the Landslide SDK.
The Landslide SDK is 100% compatible with the Cosmos SDK, with a few minor changes made to support Avalanche consensus and remove the Tendermint consensus and slashing modules. Therefore, the process of deploying contracts onto the Landslide network should be relatively straightforward for dApps that are already built using the Cosmos SDK.
What happens if an Avalanche validator signs two different blocks at the same height?
Currently, nothing happens. In Avalanche, block signing only occurs during the block proposal process, not during the validation process. Therefore, double-signing is not treated as an attack.
Don't validators still have to sign a vote for the block during the consensus process?
No, validators do not sign a vote for the block during the consensus process in Avalanche.
Do you need an oracle to access the P-chain in avalanche?
No. It is possible to access the P-chain in Avalanche via IBC without the need for an oracle. IBC is a protocol that enables interchain communication between different blockchains, and it does not require oracles to function.
Additionally - you don't need IBC either. You can directly get the state you need by querying the P-chain.
How do I access Avalanche Warp Messaging (AWM)?
You can only access AVAX via the P-chain if and only if you have an IBC light client on AVAX and on the source chain side. This requires the corresponding VMs to run natively on both chains. Interchain Foundation is funding open source IBC light client work on all chains, not just AVAX.
How do you get from the current Landslide Core to a working system and the properties of the system?
To get from the current Landslide Core to a working system, developers need to implement the necessary ABCI calls in their application, including InitChain, BeginBlock, DeliverTx, CheckTx, and EndBlock ABCI calls. Once implemented, the dApp can be compiled using the LandslideSDK and deployed to the Avalanche network.
LandslideCore is an implementation of the Tendermint Core that has been extended to include support for the Avalanche network. It provides the core functionality for creating and managing blockchain applications on the Avalanche network.
One important aspect of expanding the Landslide ecosystem is the development of an open source IBC light client, which is being funded by the Interchain Foundation. This light client will allow Avalanche to communicate with other blockchain networks that also support IBC, enabling cross-chain communication and interoperability.
LandslideCore and LandslideSDK are important components in the development of this IBC light client, as they provide the necessary tools and infrastructure for building and deploying dApps on the Avalanche network. With the help of LandslideCore and LandslideSDK, developers can create and manage dApps that communicate with other blockchain networks through IBC, expanding the capabilities and reach of the Avalanche network.
Doesn't Cosmos already have very fast finality?
The speed of finality in Cosmos chains can vary depending on the chain's configuration and the number of validators in its network. Some Cosmos chains may achieve fast finality times of a few seconds, while others may have longer finality times. However, Avalanche's consensus mechanism is designed to achieve sub-second finality times even with a large number of validators. This is achieved through its use of probabilistic consensus and its network subsampling algorithm, which allows for a high degree of scalability without compromising security.
Where is the Avalanche consensus implemented?
The consensus algorithm implemented in the reactor.go file of the LandslideCore repository is the Avalanche consensus algorithm. This implementation includes the following key components:
Sampling: A network subsampling algorithm is used to gather opinions from a random subset of the validator set.
Metastability: The algorithm is designed to be meta-stable, meaning that it can tolerate temporary partitions or forks in the network without compromising safety.
Binary consensus: Each validator in the subsample independently chooses between two binary values (e.g., 0 or 1) and broadcasts their decision to the rest of the subsample.
Repeated subsampling: If the subsample reaches consensus, the decision is propagated up to a larger subsample until the full validator set reaches agreement.
Overall, the Avalanche consensus algorithm is designed to be scalable, secure, and fast, with finality times on the order of seconds rather than minutes or multiple seconds.
How does Tendermint increase latency as you scale the validator set?
Tendermint consensus protocol requires validators to communicate with each other to come to an agreement on the next block. As the number of validators increases, the number of communication channels also increases, which can lead to increased network latency. This can result in a longer time for blocks to be propagated and finality to be achieved. In other words, as the validator set grows, the network may experience delays in block creation and confirmation. This is a known issue with Tendermint consensus, and is why other consensus protocols, like Avalanche, have been developed to address this scalability challenge.
How does Avalanche ensure token fungibility across subnets?
Token fungibility is VM specific, but the current recommendation is to treat tokens on different subnets as not fungible, just like in Cosmos. The Cosmos team is implementing path unwinding to improve token fungibility, as discussed here.
The first standard for token fungibility on Avalanche is likely to be based on the messaging format introduced into Subnet EVM, which is agnostic to token logic, and the Teleporter contract format that specifies fungibility. Ava Labs is currently working on this internally, and there are no official developer documents available yet.
If a token is minted on Subnet A and sent to Subnet B, and then wants to be sent to Subnet C, it will generally be forwarded through Subnet A.
How does the IBC light client send packet data?
Please refer to the official IBC documentation here, and check out a detailed diagram of the AVAX IBC light client here.
Packet data in IBC refers to the messages that are sent between two independent chains over the IBC protocol. The packet data contains information on the transaction or asset transfer, such as the sender, recipient, amount, and any additional metadata.
To build an IBC light client for AVAX, you would need to create a light client that can verify and validate packet data from other chains. The light client must be able to confirm that the packet data received is valid and that it has not been tampered with during transmission.
In the context of the IBC protocol, a light client is a simplified version of a full node that can verify the headers of blocks from another chain. Light clients can use a cryptographic proof to verify that the block headers are valid without having to download and store the entire blockchain.
The IBC documentation provides a detailed overview of how light clients can be used to verify packet data from other chains. It describes the different components of an IBC light client, including the header, proof, and verification algorithm.
Landslide's IBC light client for AVAX verifies and validates packet data from other chains using the existing open source IBC light client specification and appropriate cryptographic algorithms.
What is the method for obtaining a specific validator set and its associated proof for the C-Chain, especially when this information is stored in the block header?"
Use this API to get the validator set: https://docs.avax.network/reference/avalanchego/p-chain/api#platformgetvalidatorsat
How does the Avalanche light client handle the selection and updating of its validator set in comparison to Ethereum's Altair light client, which updates its 512-member validator set every 256 epochs?
In Avalanche, a partial validator set is randomly chosen from the entire pool of available validators to sign blocks. The Avalanche Light Client operates by setting a certain threshold—often a two-thirds majority—of these selected validators whose signatures are required to verify a block. Unlike Ethereum's Altair light client, which updates its validator set every 256 epochs (approximately every 27 hours), the Avalanche Light Client follows its own unique schedule and methodology for updating and validating its validator set.
How does the Landslide token accrue value?
The only security assumption that IBC has is that the target and the source chain are valid. Unlike major bridges like LayerZero, ChainLink, or Wormhole, there are no assumptions that the bridge is valid, because there are no externally verified bridge validators on IBC; there are only relayers relaying packets between chains. Landslide tokens create value by (1) securing a subnet, and (2) processing volume to/from Avalanche over IBC.
What's the user experience like? Do you need to hold Landslide tokens in order to swap assets?
Landslide tokens are abstracted away from the users via Burnt’s generalized abstraction layer. The aim is to optimize the tokens so that users do not need to hold SLIDE tokens to swap between Cosmos/AVAX assets; the token is abstracted away from the user..
Last updated