Quick Take

• Positions Avalanche well to become one of the lowest latency, highest throughput EVM L1 experiences in the ecosystem.
• Avalanche validators increased the C-Chain’s target gas consumption by 30% from 1.6M to 2.1M gas/second
• The dynamic adjustments were enabled by the Octane upgrade that activated in April 2025.
• The Avalanche Foundation plans to continue signaling for incremental increases, as network performance metrics allow
• Future improvements like Streaming Asynchronous Execution (SAE) and Firewood Database integration aim to enable even larger increases

Avalanche’s C-Chain has seen its throughput capacity increase by over 30% following validator action to raise the target gas consumption from 1.6 million to 2.1 million gas per second. The increase was made possible by the Octane upgrade that went live on April 6th, 2025.

The gas target determines how much computational work the network can process per second, directly affecting how many transactions and smart contract operations can be executed. For users of the chain, higher gas targets mean higher potential transactions per second, and also lower transaction fees. For validators and node operations, higher gas targets can mean increased demands on hardware and network infrastructure, which is closely monitored to ensure stability and reliability.

Dynamic Gas Target Adjustment

The Octane upgrade introduced the ability for Avalanche Primary Network validators to dynamically update the network’s target utilization through signaling their preferences. This mechanism allows the network to adjust capacity parameters without requiring hard forks or governance votes.

How Validator Signaling Works

Under the new mechanism, validators can explicitly set their preferred gas target values. Validators that do not set a preference effectively abstain from influencing the network’s gas target by defaulting to whatever the current value is. The network calculates the effective gas target based on the preferences of participating validators.

Since the upgrade’s activation, validators run by the Avalanche Foundation have iteratively increased their gas target preferences, resulting in the 30% throughput increase observed across the network.

The Avalanche Foundation plans to continue gradually increasing their validator preferences while monitoring network performance metrics. This approach aims to maximize C-Chain utilization within current infrastructure constraints. Upcoming optimizations like Streaming Asynchronous Execution and the Firewood Database integration are expected to enable further increases.

Other validator operators can set their gas target preferences to participate in determining the network’s effective throughput capacity. This allows scaling decisions to reflect the technical assessment of the broader validator community.

Network Health Monitoring

Several key performance indicators are closely monitored consistently through changes to the target gas consumption to ensure network stability:

• Block verification times — to ensure consensus remains stable

As the gas target increases, so does the maximum amount of gas able to be consumed in a given block. The more gas in a block, the longer time that block will potentially take to execute. It’s important that block execution times remain within an acceptable range to ensure that consensus is able to proceed successfully.

Because blocks can have significantly different sizes depending on the time they are produced and gas capacity available at that instant, a holistic way of viewing the amount of time spent in block execution is by looking at the percentage of time that a node uses to execute blocks during consensus. We had earmarked less than or equal to 5% of time spent in block execution as a key performance indicator of consensus, and though a small initial increase was observed, validator nodes were able to stay below that threshold.

• Disk usage and state growth rates — to monitor storage requirements

The higher the gas usage, the higher potential for state growth, and because all validators currently must maintain the full state of the chain on disk, the more storage validators may need to have available to use.

Of course the larger the chain grows, the more disk space it will require to store it, but in increasing the gas target we wanted to ensure that the rate of disk growth didn’t become unsustainable, and in fact observed that disk usage continued to grow at a relatively constant rate of around 3 to 4 GB per day.

Interestingly, since the increases to the gas target, we have observed a slight decrease in the amount of data added to disk per gas used. Meaning that as more gas became available, a smaller percentage of the total gas was used to write new values to state.

• Peer-to-peer network health — to monitor connectivity between all validator nodes

A key indicator of the health of the network as a whole is the percentage of successful queries made to peers. If any significant number of validator nodes were to not be able to process the increased utilization level of the chain, they would not be able to respond to their peer’s queries about block proposals. Throughout the iterative increases to the gas target in June and July, we did not observe any noticeable decrease in the observed percentage of successful queries, indicating that on the whole, the vast majority of nodes are still stable and able to keep up with the increased processing demands created by the higher gas targets.

These metrics remained within acceptable parameters throughout the increase, indicating the network can handle the higher throughput without stability issues.

Scaling Optimization Ahead

The 30% increase represents just the beginning of Avalanche’s throughput expansion plans. Two major technical upgrades are in development that could enable even more significant capacity improvements:

Streaming Asynchronous Execution (SAE)

As outlined in Avalanche Community Proposal ACP-194, SAE introduces a fundamental architectural change by separating block execution from the consensus process. This allows for a continuous execution thread that operates independently of consensus, enabling gas targets to align with average-case execution times rather than being constrained by worst-case scenarios.

The separation means the network can maintain higher throughput targets without risking consensus delays during computationally intensive blocks.

Firewood Database Integration

The upcoming Firewood database integration is designed to significantly improve performance of blockchain database operations, and also reduce validator node storage requirements through optimized data layout and state pruning. By maintaining only recent state data and improving storage efficiency, Firewood will reduce the operational burden on validators, potentially enabling support for higher gas targets.

Looking Ahead

A combination of upcoming performance improvement efforts as well as continued iteration to dynamically determine the maximum chain capacity possible at any given point in time positions Avalanche well to become one of the lowest latency, highest throughput EVM L1 experiences in the ecosystem.

Head to the Builders Hub to access everything you need to know about building on Avalanche: https://build.avax.network/

Introduction

Avalanche is a platform that powers the execution transactions for decentralized applications. It’s comprised of subnetworks called Subnets consisting of custom virtual machines (VMs) and complex validator rulesets. One such VM is Subnet-EVM. This technical deep-dive reviews how Subnet-EVM can customize the VM’s deployment via Stateful Precompiles, allowing for Subnets to adapt to all of your dApp’s needs.

Subnet-EVM

Avalanche is a network composed of many blockchains. Each blockchain is an instance of a VM, much like an object is an instance of a class in an object-oriented language. That is, the VM defines the behavior of the blockchain.

Subnet-EVM is a simplified version of Coreth, the VM of the Contract Chain (C-Chain). It implements the Ethereum Virtual Machine (EVM) and supports Solidity smart contracts, as well as most other Ethereum client functionality, and is compatible with many of EVM toolchains and wallets.

EVM Precompile

Originally defined in Appendix E of the Ethereum Yellowpaper, precompiled contracts are written in low-level code and are responsible for implementing operations or computations that are used by smart contracts. These precompiled contracts provide efficient and optimized implementations of cryptographic operations. They’re included in the EVM protocol to enable smart contracts to perform complex computations, without the need for developers to write custom code.

PrecompiledContract

All Precompiles must implement the PrecompiledContract interface

// PrecompiledContract is the basic interface for native Go contracts. 
// The implementation requires a deterministic gas count based on the 
// input size of the Run method of the contract.
type PrecompiledContract interface {
    RequiredGas(input []byte) uint64
    Run(input []byte) ([]byte, error)
}

PrecompileContract has 2 functions which need to be implemented. RequiredGas calculates the contract gas use and Run runs the precompiled contract.

NOTE the PrecompiledContract is different than the StatefulPrecompiledContract listed below.

These precompile addresses start from 0x0000000000000000000000000000000000000001 and increment by 1.

EVM Precompiled contracts include the following. The numbering is the address of the contract:

1. Recovery of ECDSA signature
2. Hash function SHA256
3. Hash function RIPEMD160
4. Identity
5. Modular exponentiation (EIP 198)
6. Addition on elliptic curve alt_bn128 (EIP 196)
7. Scalar multiplication on elliptic curve alt_bn128 (EIP 196)
8. Checking a pairing equation on curve alt_bn128 (EIP 197)
9. BLAKE2b hash function (EIP 152)

Precompiles are shortcuts to execute a function implemented by the EVM itself, rather than an actual contract. They’re useful when the desired functionality would be cumbersome and awkward to implement in Solidity, such as cryptographic functions. Here’s the RIPEMD160 cryptographic function implemented as a precompile. Note that it implements the RequiredGas and Run functions per the PrecompiledContract interface.

RIPEMD160 Implementation

// RIPEMD160 implemented as a native contract.
type ripemd160hash struct{}

// RequiredGas returns the gas required to execute the pre-compiled contract.
//
// This method does not require any overflow checking as the input size 
// gas costs
// required for anything significant is so high it's impossible to pay for.
func (c *ripemd160hash) RequiredGas(input []byte) uint64 {
 return uint64(len(input)+31)/32*params.Ripemd160PerWordGas + params.Ripemd160BaseGas
}

func (c *ripemd160hash) Run(input []byte) ([]byte, error) {
 ripemd := ripemd160.New()
 ripemd.Write(input)
 return common.LeftPadBytes(ripemd.Sum(nil), 32), nil
}

Developers can leverage precompiles by invoking the keywords:

return ripemd160hash(input)

Behind the scenes, precompiles are triggered through CALL opcodes utilizing specific addresses. These CALL opcodes, including CALL, STATICCALL, DELEGATECALL, and CALLCODE, have the ability to invoke a precompile. Typically, these opcodes are employed to call a smart contract, with the input representing encoded parameters for the smart contract call. However, when a precompile is involved, the input is passed to the precompile, allowing it to execute the operation and deduct the necessary gas from the transaction's execution context.

Here are the original 9 cryptographic functions implemented as precompiles:

1. Recovery of ECDSA signature
2. Hash function SHA256
3. Hash function RIPEMD160
4. Identity
5. Modular exponentiation
6. Addition on elliptic curve alt_bn128
7. Scalar multiplication on elliptic curve alt_bn128
8. Checking a pairing equation on curve alt_bn128
9. BLAKE2b hash function

We can see these precompile mappings from address to function here in Coreth:

// PrecompiledContractsBanff contains the default set of pre-compiled Ethereum
// contracts used in the Banff release.
var PrecompiledContractsBanff = map[common.Address]precompile.StatefulPrecompiledContract{
	common.BytesToAddress([]byte{1}): newWrappedPrecompiledContract(&ecrecover{}),
	common.BytesToAddress([]byte{2}): newWrappedPrecompiledContract(&sha256hash{}),
	common.BytesToAddress([]byte{3}): newWrappedPrecompiledContract(&ripemd160hash{}),
	common.BytesToAddress([]byte{4}): newWrappedPrecompiledContract(&dataCopy{}),
	common.BytesToAddress([]byte{5}): newWrappedPrecompiledContract(&bigModExp{eip2565: true}),
	common.BytesToAddress([]byte{6}): newWrappedPrecompiledContract(&bn256AddIstanbul{}),
	common.BytesToAddress([]byte{7}): newWrappedPrecompiledContract(&bn256ScalarMulIstanbul{}),
	common.BytesToAddress([]byte{8}): newWrappedPrecompiledContract(&bn256PairingIstanbul{}),
	common.BytesToAddress([]byte{9}): newWrappedPrecompiledContract(&blake2F{}),

By utilizing these precompiled contracts, smart contracts can perform cryptographic computations more efficiently and with reduced gas costs. Developers can call these precompiled contracts directly from their own smart contracts, saving computational resources and simplifying the development process.

Precompiled contracts are an integral part of any EVM ecosystem, providing optimized implementations of cryptographic operations for smart contracts.

Stateful Precompile

Avalanche enables precompiles to have greater functionality by adding state access. There are 5 stateful precompiles which can be enabled via ChainConfig in genesis or as an upgrade.

• Restricting Smart Contract Deployers
• Restricting Who Can Submit Transactions
• Minting Native Coins
• Configuring Dynamic Fees
• Changing Fee Reward Mechanisms

AllowList

Permissions can be enforced by a stateful precompile on an address via the AllowList interface. The AllowList is not a contract itself, but a helper structure to provide a control mechanism for wrapping contracts. It provides an AllowListConfig to the precompile so that it can take an initial configuration from genesis/upgrade.

Each Precompile, which is using AllowList , has 3 permission levels. Admin lets you create and remove other Admins in addition to using the precompile. Enabled lets you use the precompile. None prevents you from using the precompile.

pragma solidity ^0.8.0;

interface IAllowList {
  // Set [addr] to have the admin role over the precompile
  function setAdmin(address addr) external;

  // Set [addr] to be enabled on the precompile contract.
  function setEnabled(address addr) external;

  // Set [addr] to have no role the precompile contract.
  function setNone(address addr) external;

  // Read the status of [addr].
  function readAllowList(address addr) external view returns (uint256 role);
}

ContractDeployerAllowList

AllowList adds adminAddresses and enabledAddresses fields to precompile contract configurations. For instance, configure the contract deployer precompile contract configuration by adding the following JSON to your genesis or upgrade JSON.

ContractDeployerAllowList enables restricting which accounts can deploy a smart contract to your instance of Subnet EVM. Configure by adding the following JSON to your genesis or upgrade JSON.

"contractDeployerAllowListConfig": {
    "adminAddresses": [
        "0x41B3E74d0dC7c5f573c8cFB007C45a494B1B10F7"
    ],
    "enabledAddresses": [
        "0x7326165202aed51E8dd3750Ff59a048F73579960"
    ],
    "blockTimestamp": 0
},

The Stateful Precompile contract, which powers the ContractDeployerAllowList, adheres to the AllowList Solidity interface at 0x0200000000000000000000000000000000000000 (you can load this interface and interact directly in Remix).

ContractNativeMinter

ContractNativeMinter enables restricting, which accounts can mint native(gas) coins. Configure this by adding the following JSON to your genesis or upgrade JSON.

"contractNativeMinterConfig": {
    "adminAddresses": [
        "0x717b7948AA264DeCf4D780aa6914482e5F46Da3e"
    ],
    "enabledAddresses": [
        "0x3287591FC6C6Ef2E7AcF9293f458ECAA6Ed9bc63"
    ],
    "blockTimestamp": 0
},

The Stateful Precompile contract powering the ContractNativeMinter adheres to the following Solidity interface at 0x0200000000000000000000000000000000000001 (you can load this interface and interact directly in Remix):

pragma solidity ^0.8.0;
import "./IAllowList.sol";

interface INativeMinter is IAllowList {
// Mint [amount] number of native coins and send to [addr]
  function mintNativeCoin(address addr, uint256 amount) external;
}

TxAllowList

TxAllowList enables restricting which accounts can submit a transaction to your instance of Subnet EVM. Configure this by adding the following JSON to your genesis or upgrade JSON.

"txAllowListConfig": {
    "adminAddresses": [
        "0xB79FFB4eCaAb0135062c86F24dd2ff75112b646C"
    ],
    "enabledAddresses": [
        "0xCa0F57D295bbcE554DA2c07b005b7d6565a58fCE"
    ],
    "blockTimestamp": 0
},

The Stateful Precompile contract powering the TxAllowList adheres to the AllowList Solidity interface at 0x0200000000000000000000000000000000000002 (you can load this interface and interact directly in Remix):

FeeManager

FeeManager enables configuring the parameters of the dynamic fee algorithm. Configure this by adding the following JSON to your genesis or upgrade JSON.

"feeManagerConfig": {
    "adminAddresses": [
        "0x99ef71E554E54a7135d032ab30FC476DC55f9315"
    ],
    "enabledAddresses": [
        "0x7B137BB4704b977a23Cc8055C2C87674B730aa0a"
    ],
    "blockTimestamp": 0
},

The Stateful Precompile contract powering the FeeConfigManager adheres to the following Solidity interface at 0x0200000000000000000000000000000000000003 (you can load this interface and interact directly in Remix).

pragma solidity ^0.8.0;
import "./IAllowList.sol";

interface IFeeManager is IAllowList {
// Set fee config fields to contract storage
  function setFeeConfig(
    uint256 gasLimit,
    uint256 targetBlockRate,
    uint256 minBaseFee,
    uint256 targetGas,
    uint256 baseFeeChangeDenominator,
    uint256 minBlockGasCost,
    uint256 maxBlockGasCost,
    uint256 blockGasCostStep
  ) external;

// Get fee config from the contract storage
  function getFeeConfig()
    external
    view
    returns (
      uint256 gasLimit,
      uint256 targetBlockRate,
      uint256 minBaseFee,
      uint256 targetGas,
      uint256 baseFeeChangeDenominator,
      uint256 minBlockGasCost,
      uint256 maxBlockGasCost,
      uint256 blockGasCostStep
    );

// Get the last block number changed the fee config from the contract storage
  function getFeeConfigLastChangedAt() external view returns (uint256 blockNumber);
}`

RewardManager

RewardManager enables configuring the fee reward mechanism, including burning fees, sending fees to a predefined address, or enabling fees to be collected by block producers. Configure this by adding the following JSON to your genesis or upgrade JSON.

"rewardManagerConfig": {
    "adminAddresses": [
        "0x99ef71E554E54a7135d032ab30FC476DC55f9315"
    ],
    "enabledAddresses": [
        "0x7B137BB4704b977a23Cc8055C2C87674B730aa0a"
    ],
    "blockTimestamp": 0,
    "initialRewardConfig": {
        "allowFeeRecipients": true,
        "rewardAddress": "0x0000000000000000000000000000000000000000"
    }
},

The Stateful Precompile contract powering the RewardManager adheres to the following Solidity interface at 0x0200000000000000000000000000000000000004 (you can load this interface and interact directly in Remix).

pragma solidity ^0.8.0;
import "./IAllowList.sol";

interface IRewardManager is IAllowList {
// setRewardAddress sets the reward address to the given address
  function setRewardAddress(address addr) external;

// allowFeeRecipients allows block builders to claim fees
  function allowFeeRecipients() external;

// disableRewards disables block rewards and starts burning fees
  function disableRewards() external;

// currentRewardAddress returns the current reward address
  function currentRewardAddress() external view returns (address rewardAddress);

// areFeeRecipientsAllowed returns true if fee recipients are allowed
  function areFeeRecipientsAllowed() external view returns (bool isAllowed);
}

CALL

The CALL opcode (CALL, STATICCALL, DELEGATECALL, and CALLCODE) allows us to invoke this precompile.

The function signature of CALL in the EVM is as follows:

Call(
    caller ContractRef,
    addr common.Address,
    input []byte,
    gas uint64,
    value *big.Int,
)(ret []byte, leftOverGas uint64, err error)

When a precompile is called, the EVM checks if the input address is a precompile address. If the input address is a precompile address, it executes the precompile. Otherwise, it loads the smart contract at the input address and runs it on the EVM interpreter with the specified input data.

Calling a Precompile from Solidity

Remix comes with a simple contract called Storage.sol, which lets you write/read a number to/from the blockchain. Open Storage.sol and add the following hashNumber function.

/**
     * @dev Return hash 
     * @return hash
     */
    function hashNumber() public view returns (bytes32 hash) {
        (bool ok, bytes memory out) = address(2).staticcall(abi.encode(number));
		require(ok);
        hash = abi.decode(out, (bytes32));
        return hash;
    }

hashNumber returns the sha256 hash of number by calling the sha256 precompile located at address(2) or 0x000000000000000000000000000000000002.

The complete Storage.sol contract should look like this:

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.7.0 <0.9.0;

/**
 * @title Storage
 * @dev Store & retrieve value in a variable
 * @custom:dev-run-script ./scripts/deploy_with_ethers.ts
 */
contract Storage {

    uint256 number;

    /**
     * @dev Store value in variable
     * @param num value to store
     */
    function store(uint256 num) public {
        number = num;
    }

    /**
     * @dev Return value 
     * @return value of 'number'
     */
    function retrieve() public view returns (uint256){
        return number;
    }

    /**
     * @dev Return hash 
     * @return hash
     */
    function hashNumber() public view returns (bytes32 hash) {
        (bool ok, bytes memory out) = address(2).staticcall(abi.encode(number));
  require(ok);
        hash = abi.decode(out, (bytes32));
        return hash;
    }
}

Alternatively, you can interface with the sha256 interface directly. First, create a new file called Isha256.sol and paste in the following contents and save the file.

// SPDX-License-Identifier: MIT

pragma solidity >=0.8.0;

interface ISHA256 {

    // Computes the SHA256 hash of value
    function run(string memory value) external view returns (bytes32 hash);
}

Switch to the “Deploy & Run Transactions” view in the left sidebar. Select the Injected Provider as the environment, let Core connect to Remix, and paste this precompile address below in the “At Address” field: 0x0000000000000000000000000000000000000002

Next, click the blue ”At Address” button. A new compiled contract appears below. Click the small arrow next to SHA256 and call the function with any string.

You can see the return value of the hash function below the input field.

Avalanche Stateful Precompile

A stateful precompile builds on a precompile and adds state access. Stateful precompiles are not available in the default EVM, and are specific to Avalanche EVMs such as Coreth and Subnet-EVM.

A stateful precompile follows this interface:

// StatefulPrecompiledContract is the interface for executing a 
// precompiled contract
type StatefulPrecompiledContract interface {
    // Run executes the precompiled contract.
    Run(accessibleState PrecompileAccessibleState,
    caller common.Address,
    addr  common.Address,
    input []byte,
    suppliedGas uint64,
    readOnly bool)
    (ret []byte, remainingGas uint64, err error)
}

NOTE the StatefulPrecompiledContract is different than the PrecompiledContract listed above.

Precompile-EVM

Precompile-EVM is a repository for registering precompiles to Subnet-EVM without forking the Subnet-EVM codebase. Subnet-EVM supports registering external precompiles through precompile/modules package. By importing Subnet-EVM as a library, you can register your precompiles to Subnet-EVM and build it together with Subnet-EVM.

HelloWorld is an example stateful precompile that ships with Precompile-EVM. Here we’re going to configure and deploy that precompile. Next, create a new precompile using code generation scripts that ship with Precompile-EVM. The example precompile will have the same functionality as HelloWorld and will serve primarily as example steps for using the code generation scripts.

Clone the Repo

1. Clone the Precompile-EVM GitHub repo to your local machine.

git clone <https://github.com/ava-labs/precompile-evm.git>
cd precompile-evm/

Checkout the hello-world-example Branch

2. Once you have the Precompile-EVM repo, check out the appropriate branch.

git checkout hello-world-example

Install Dependencies

3. Next, you have to cd contracts/ and run npm install to get the dependencies. You’ll need the latest version of NodeJS installed which comes bundled with npm.

cd contracts/
npm install
cd ../

Config the HelloWorld Precompile

The configuration file for the HelloWorld precompile is located at tests/precompile/genesis/hello_world.json. In addition to the HelloWorld precompile, you can add config for any existing precompiles. You can also config the Subnet’s tokenomics, which include initial coin allocation. By default, it’s configured to airdrop 1M of your Subnet’s gas token to 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC, which is the address derived from 0x56289e99c94b6912bfc12adc093c9b51124f0dc54ac7a766b2bc5ccf558d8027 which is a private key that we share publicly in our docs and use for airdropping tokens onto new networks.

You can also add any other addresses and balances which you want to airdop on your new subnet.

"alloc": {
    "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": {
      "balance": "0x52B7D2DCC80CD2E4000000"
    }
  },

Additionally, you can config additional precompiles. Let’s update hello_world.json to enable the 0x8db from above to be able to mint additional gas tokens.

"contractNativeMinterConfig": {
      "adminAddresses": [
          "0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"
      ],
      "blockTimestamp": 0
    }

You also want to enable and configure the HelloWorld precompile.

"helloWorldConfig": {
      "blockTimestamp": 0,
      "adminAddresses": [
        "0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"
      ]
    },

Start a Local Network

Using the Avalanche Network Runner, fire up a server

avalanche-network-runner server

In a different tab, start a 5 node network

avalanche-network-runner control start \\
  --number-of-nodes=5 \\
  --blockchain-specs '[{"vm_name": "subnetevm", "genesis": "./tests/precompile/genesis/hello_world.json"}]'

After the network is finished building, you should see RPC URIs in the logs

[07-25|17:02:18.113] INFO server/network.go:649 [blockchain RPC for "srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy"] "<http://127.0.0.1:9650/ext/bc/2RQiKekQrhAR7maFz1PSF9MCs6kH3SyMAMLWVP4zossXkq6SDJ>"

Connect a Wallet to the Subnet

In MetaMask, on the network dropdown, select “Add network”

On the next page, select “Add a network manually”

On the last page, enter the RPC information. Note you want to add /rpc at the end of the RPC uri from the Avalanche Network Runner logs.

Now, you should be successfully able to join

Import Funded Account

In hello_world.json , we allocated 1m gas tokens to the 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC address. To import the key, select the dropdown menu from the first account and select “Import amount”

Next, paste in the private key 0x56289e99c94b6912bfc12adc093c9b51124f0dc54ac7a766b2bc5ccf558d8027

Once the account is imported, it will have a 1M token balance.

Remix

Now, connect Remix to the wallet to interact with the precompiles on the Subnet. Head to Remix and under the “Deploy and Run Transactions” tab along the left select the “Environment” drop-down menu, select Injected Provider.

A MetaMask popup will ask which accounts to connect to Remix. Select both addresses so that either can interact with the blockchain.

You can now mint additional HW tokens. As mentioned above, you can interface with the ContractNativeMinter precompile at 0x0200000000000000000000000000000000000001. In the “File Explorer” tab, open INativeMinter.sol or create a new file and paste into the INativeMinter interface.

Once open, compile the interface in the “Deploy and Run Transactions” tab and paste the address for the INativeMinter interface, 0x0200000000000000000000000000000000000001 into the “Add Address” input field and click “Add Address.”

Remix will show a form with input fields, that match the Solidity interface. First, paste the address into the readAllowList input field and note it returns “role 2” which signifies that address has admin permissions for the precompile.

Enter the address of the account you want to mint more tokens to, in this case, 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC, and the amount of tokens to mint

We’ve minted 1234 new tokens and the balance shows in Metamask.

HelloWorld Precompile

Now, we can interface with the HelloWorld precompile. Head over to Remix and create a new .sol file. Paste the IHelloWorld.sol interface

pragma solidity >=0.8.0;
import "@avalabs/subnet-evm-contracts/contracts/interfaces/IAllowList.sol";

interface IHelloWorld is IAllowList {
  // sayHello returns the stored greeting string
  function sayHello() external view returns (string calldata result);

  // setGreeting  stores the greeting string
  function setGreeting(string calldata response) external;
}

The HelloWorld precompile is located in the helloworld/ directory. In helloworld/module.go , look for the ContractAddress variable to see at what hex address the precompile is deployed.

var ContractAddress = common.HexToAddress("0x0300000000000000000000000000000000000000")

Also, look in plugin/main.go and confirm that helloworld is being imported.

_ "github.com/ava-labs/precompile-evm/helloworld"

Open IHelloWorld.sol in Remix and compile it.

In the “Deploy and Run Transactions” tab, enter 0x0300000000000000000000000000000000000000 into the “At Address” input field to bring up a GUI for interacting with HelloWorld. Next, click sayHello and you will see the string “Hello World.” This is being read from the stateful precompile!

Now, enter “hola mundo” into the setGreeting field and submit that transaction. Once it’s successful, click sayHello again and you will see the string “hola mundo.” This has successfully wrote and read to the blockchain via the stateful precompile! 🏆

Conclusion

EVM Precompiles provides an API for developers to create optimized and efficient implementations of functionality in Go, as opposed to implementing the functionality in Solidity. Avalanche Stateful Precompiles go one step further by providing access to State.

We introduced precompiles and their history going all the way back to the Ethereum Yellow paper. We also introduced Stateful Precompiles and showed how to interface with the 5 stateful precompiles which come bundled with Subnet EVM. Using those learnings, we then showed you how to clone Precompile EVM and interact with the HelloWorld stateful precompile.

In the current blockchain development environment, there is a large amount of technology being built to solve the issue of scalability present within blockchain-based networks. As the demand for blockspace in traditional blockchain networks escalates, so does the network traffic, resulting in reduced performance, higher transaction fees, and increased congestion, all of which render the network less effective. In response to this, the industry has evolved to address these challenges and build forward.

This has led to a mass influx of new solutions being built and broadly speaking, these solutions tend to fall into one of three categories: Layer 2 Scaling Solutions, Application Specific Environments, and Modular Focused Development.

• Layer 2 Scaling Solutions: These systems aim to alleviate the stress on the main blockchain network, referred to as Layer 1, by handling transactions off-chain. Examples include Lightning Network for Bitcoin and Zero Knowledge and Optimistic Rollups for Ethereum. By conducting transactions off the main chain, these solutions allow for higher transaction throughput and lower fees, while still ensuring a level of security and decentralization.
• Application Specific Environments: These are intricately tailored platforms designed for dedicated applications — taking the load off the primary network and offloading to a dedicated chain. This offers a high degree of customization to optimize and align with the requirements of a specific use case, with the intent of bolstering both performance and operational efficiency. The flexibility and targeted nature of these environments allow them to deliver high throughput and enhanced user experiences, potentially revolutionizing the way blockchain technology is applied across various sectors.
• Modular Focused Development: This approach emphasizes the creation of modular, reusable components. By allowing developers to focus on individual modules, this model promotes flexibility, efficiency, and easier maintenance, speeding up development and ensuring robustness in the face of changing requirements or technological landscapes.

Each of these strategies presents its own advantages, offering unique solutions to the scalability issue, and contributing to the ongoing evolution and refinement of blockchain technology. However, our exploration doesn’t stop there. A fourth category is emerging, paving a new path in this dynamic landscape and representing a different approach to scalability and customization in blockchain technology.

In the pursuit of addressing inherent challenges with blockchains surrounding scalability and customization, we reviewed 3 different platforms and architectures, each with its own solutions that allow developers or groups to launch and operate their individual blockchains.

These three solutions are:

• Avalanche Subnets
• Polygon Supernets
• Cosmos Zones

(Note: We acknowledge that this list is not exhaustive and future work will focus on other app chain scaling solutions and architectures)

In this analysis, we have reviewed each solution and will specifically comment on the following variables:

• Core Architecture/Technology: This refers to the fundamental design and structure of the blockchain network, including the algorithms and protocols used for transaction processing, consensus, and security. Different architectures can lead to significant differences in the capabilities and characteristics of a blockchain.
• Scalability: Scalability is the ability of a blockchain to handle a growing amount of work or its potential to accommodate growth. Scalability is a major concern for many blockchains, as increased usage can lead to slower transaction times and higher costs.
• Speed: This refers to the rate at which transactions are processed and confirmed on the blockchain. Speed is a crucial factor for many applications of blockchain technology, especially those that require real-time or near-real-time transaction processing.
• Customizability: This refers to the extent to which a blockchain system can be tailored or modified to meet specific needs or requirements. Some blockchains are designed to be highly customizable, allowing developers to create their own smart contracts or applications on top of the blockchain. Customizability can be a key factor for businesses or developers looking to use blockchain technology for specific use cases.
• Security: Security in a blockchain context refers to the measures and features that protect the blockchain and its users from different types of attacks or fraudulent activities, including cryptographic techniques, consensus mechanisms, and other protective measures.

Core Network Architecture

Avalanche

Fundamentally, Avalanche is an open-source, permissionless protocol that anyone can leverage to establish their own distinct blockchain network powered by a novel consensus mechanism. The Avalanche family of consensus protocols enables Avalanche to provide sub-second, immutable finality.

This consensus mechanism is a significant improvement over previous consensus protocols. By combining the best features of Classical and Nakamoto consensus mechanisms, Avalanche consensus sets a new standard for powering high throughput, enabling near-instant finality, maintaining energy efficiency, and providing the ability to scale to infinite validators.

This efficiency is achieved through a process called “random subsampling,” where nodes in the network query a random subset of other nodes in the network to accept or reject a proposed transaction.

Random subsampling allows for sub-second transaction finality — meaning that transactions are finalized on the Avalanche blockchain in under 1 second before being propagated into the block, which has block times of less than 2 seconds, ensuring that transactions are quickly confirmed and irreversible. This also allows Avalanche to theoretically handle thousands of transactions per second, as the nodes can reach consensus faster and more efficiently, enabling the network to scale to an infinite number of participants. You can learn more about the novel Avalanche Consensus here.

On top of that consensus mechanism lies the Avalanche Primary Network, which is composed of 3 primary blockchains, each of which serves a unique purpose within the chain.

The Platform Chain (P-Chain) is responsible for coordinating validators, managing Subnets (custom validator sets), and handling the creation of new blockchains within the Avalanche ecosystem. It also handles the staking provisions for validators to participate in Avalanche Consensus.

The Contract Chain (C-Chain) runs an instance of the Ethereum Virtual Machine (EVM) running on the Avalanche Network. It is compatible with Ethereum’s Solidity smart contracts and tooling, allowing developers to easily deploy Ethereum-based decentralized applications dApps) on Avalanche while utilizing Avalanche’s robust consensus. Smart contract execution with a high level of security, speed, and scalability.

The Exchange Chain (X-Chain) is the default asset chain on Avalanche for creating, issuing, or transferring assets. It powers asset transfers internally across the Avalanche ecosystem and externally to bridge to networks like Bitcoin and Ethereum.

Subnets: A subset of the Primary Network validators that agree to validate and host one or many blockchains.

The unique design of Avalanche Subnets allows for a highly personalized set of validators, with the ability to define their governing rules, facilitating the creation of a network of blockchains capable of running any virtual machine, and configured in either a permissioned or permissionless way. Learn more about Subnets here.

At the virtual machine level, this flexibility allows developers to run a dedicated instance of the Ethereum Virtual Machine (EVM) for specific applications or as a scalability solution for Ethereum. Alternatively, they can operate a modified version of the EVM, equipped with stateful precompiles, to tailor its functionalities to their needs, such as adding allow lists, ensuring KYC/AML compliance, or enabling gasless relayers.

Developers also have the freedom to launch entirely custom non-EVM virtual machines. This could include complete smart contract virtual machines such as MoveVM or Solana VM, or even application-specific VMs, such as TokenVM or IndexVM, designed to cater to specific use cases.

At the validator level, this flexibility supports both permissionless and permissioned building models. Projects can set restrictions based on various parameters such as geographical locations and KYC compliance for validators or opt for a completely permissionless configuration with their native staking token through Elastic Subnets. All of these diverse setups are interconnected seamlessly through Warp Messaging, enhancing the overall network efficiency and scalability.

Paired with a managed blockchain service platform like AvaCloud, the suite of tooling surrounding the Subnet ecosystem is growing.

Polygon

(As of the time of writing this, the latest information is based on developments up to May of 2023. At this point, there has not been any announcement regarding a significant update or evolution such as a “Polygon 2.0.” Consequently, some of the details and insights shared here may have evolved or become outdated after this date. Please consult the most recent resources or directly visit the official Polygon website for the latest and most accurate information.)

Polygon is a scaling solution built to improve the performance of the Ethereum blockchain by using “sidechains,” which are separate blockchain networks that run parallel to the Ethereum main chain. These side chains handle computations and transactions off of the Ethereum main chain, which reduces the load on the main chain. The side chains periodically provide the main chain with a summary of their activity through their ‘plasma bridge’.

Polygon employs a Proof of Stake (PoS) consensus algorithm for securing its side chain. In this system, validators actively participate in the network and voluntarily lock up or ‘stake’ their tokens as a form of collateral, making their role involves validating transactions and appending new blocks to the blockchain.

Polygon pairs this approach with the use of the Istanbul Byzantine Fault Tolerance (IBFT) consensus protocol. IBFT is a variation of the Practical Byzantine Fault Tolerance (PBFT) algorithm, specifically designed to cope with adverse conditions in public networks and provides a certain level of finality. IBFT limits permissionless participation, meaning that validators have to be explicitly specified, and only those specified can participate in the consensus process. This design might seem at odds with the decentralized ethos of blockchain, as it establishes a certain level of central control in the system. While this model enables effective consensus even in the presence of faulty nodes, it does so at the cost of limiting open network participation.

The Polygon network consists of three main layers:

1. Ethereum Layer: This layer consists of a series of smart contracts deployed on the Ethereum mainnet, which oversee critical functions such as staking management, rewards distribution, and validator registration, serving as essential components for the network's operation and security.
2. Heimdall Layer: This layer consists of the PoS Heimdall nodes that run in parallel to the Ethereum mainnet. The nodes monitor the staking contracts on Ethereum’s mainnet and commit checkpoints of the network’s state to Ethereum - this periodic snapshot allows for a checkpoint into the network’s state and helps ensure data availability and finality. Heimdall nodes employ Tendermint consensus
3. Bor Layer: This layer hosts the block-producing nodes, which are periodically rearranged by nodes operating on the Heimdall layer. The primary function of the Bor nodes is to compile transactions into blocks within the Polygon sidechain infrastructure. These nodes function utilizing GoEthereum, a widely recognized implementation of the Ethereum protocol.

On top of this architecture, Polygon has a suite of different services it offers to developers, with many different product offerings. These offerings include Polygon Supernets, PolygonID, Polygon Hermes, Polygon Edge (which is being sunsetted into a new offering), and Polygon zkEVM. For this report, we will focus on their primary scaling solution — Polygon Supernets.

Supernets are Polygon’s version of the infrastructure required to spin up application-specific blockchain networks. These networks allow applications to separate themselves from Ethereum and the main Polygon Sidechain by becoming their own chain. They are designed to increase the block space on the root chain, enhancing scalability and interoperability for decentralized applications. You can learn more about Supernets here.

Cosmos

The Cosmos Network is a network of different blockchains that are interoperable with each other. The blockchains are built using the Cosmos SDK, which is an open-source framework designed for building application-specific blockchains, either public and permissionless (PoS) or permissioned running Proof of Authority.

The primary objective of the Cosmos SDK is to allow developers to create application-specific blockchains from scratch while allowing these blockchains to interoperate with one another, similar to those mentioned above.

This vision is achieved through a modular architecture, where SDK-based blockchains are constructed using composable modules, which are open source and readily available for use. Modules are essentially self-contained pieces of code that encapsulate specific functionality for a blockchain application and are designed to be composable, meaning they can be used and combined in various ways to create a custom blockchain application. Each module defines its own state and transactions and contains its own message handlers, and they also expose an interactable interface for other modules. This allows developers to build complex applications by composing simple modules together, creating their own modules, and easily integrating them into their blockchain applications.

Cosmos introduces a concept known as the Object-Capability Model, a form of Capability-Based Security. This is an approach to managing access to the state that avoids hardcoding permissions into the state machine. Instead, the state machine is initialized with a set of capabilities. These capabilities, which are defined by the references an object holds, determine what the state machine can and cannot do, including its core functionalities and limits. This model is designed to address the threat of faulty or malicious modules in a Cosmos SDK ecosystem, favoring modularity in code design and ensuring reliable encapsulation in code implementation.

All of this operates on top of the CometBFT consensus engine, a state replication engine designed for the “interchain ecosystem and beyond.” It was initially a fork of Tendermint Core but ended up succeeding Tendermint Core as the official replication engine for the interchain stack. CometBFT’s long-term vision is to become the primary choice for a replication engineer that powers application-specific blockchains.

The network is designed around a unique architecture that consists of Hubs and Zones, which work together to facilitate inter-blockchain communication and ensure the overall security of the system.

1. Zones: Independent blockchains that are connected to one or more Hubs. Each Zone operates as its own blockchain network, runs its own consensus protocol, and maintains its own ledger. This allows each Zone to be tailored for specific use cases or applications, providing the flexibility to meet different needs within the ecosystem. For example, one Zone might be optimized for high-speed transactions, while another might be designed to handle complex smart contracts. Zones are not isolated and can communicate and interact with each other by passing messages through Hubs, enabling the transfer of assets and data across different blockchains.
2. Hubs: Blockchains that are specifically designed to connect different Zones and serve as the central connection point for Zones, facilitating communication and interoperability between them. Hubs maintain the security of the network by tracking the state of each connected Zone and managing the inter-zone communication process. The Cosmos Hub, the first hub in the Cosmos Network, is an example of such a blockchain. However, the architecture of Cosmos is designed to support multiple Hubs, with the intent of creating a network of interconnected blockchains.

Having delved into the fundamental architecture of these platforms and explored the diverse capabilities they offer, it's time to assess their real-world applicability. Ultimately, these solutions are tools, and their value lies in their ability to meet the needs of those who wield them. Developers, whether they're part of large enterprises or independent innovators, have specific requirements when it comes to building their blockchains.

The main areas we will assess:

• Scalability
• Customizability
• Speed
• Security

Scalability

Scalability is a critical aspect to consider when building a blockchain network. Traditional blockchain networks often face significant challenges as they expand, leading to issues such as high transaction fees, network congestion, and an overall inability to cope with increased demand. These challenges can render a blockchain network practically inoperable at scale, posing a significant concern for any developer or enterprise aiming to launch their blockchain. In light of these challenges, it’s crucial to select a platform that can scale effectively without succumbing to these common obstacles. It’s advisable to choose a platform that not only supports growth but also maintains performance and usability even as demand escalates.

The scalability of such a platform primarily hinges on two factors:

• Ability to Scale to Infinite Validators: The platform should be able to support an increasing number of validators without compromising on performance or security. This means that as the network grows, it should be able to accommodate more validators to maintain the decentralization and security of the network.
• High Throughput: The platform should have a high transaction throughput, meaning it can process a large number of transactions per second. This is crucial for maintaining fast and efficient operations, especially as the network grows, and the number of transactions increases.

Scalability Considerations in Supernets

Supernets, with their independent blockchains for transaction processing, initially appear to offer a scalable solution compared to a primary network. However, upon closer examination, there are significant technical considerations that could potentially impact their scalability.

Limited Validators: Supernets use the PolyBFT consensus mechanism, which imposes a cap of 100 on the total number of validators across the network. This cap can have significant implications for both scalability and decentralization. Having a limited number of validators can make the consensus process more efficient, as fewer nodes need to communicate with each other to reach consensus. This can lead to faster transaction processing times, especially when the network is not heavily loaded.

This cap can limit the network’s ability to scale. As the number of Supernets and the volume of transactions increase, these 100 validators may not be able to process transactions quickly enough to keep up with the demand. This could lead to network congestion, slower transaction processing times, and potentially higher transaction fees. Moreover, the cap on validators also has implications for the decentralization of the network. Fewer validators mean that control of the network is concentrated in fewer hands, which could lead to centralization. This could potentially make the network more vulnerable to attacks or manipulation by a small group of validators.

High Throughput: Supernets operate on the Ethereum Virtual Machine (EVM) and zkEVM. While the EVM is robust and widely adopted, it has faced challenges with network congestion and high transaction fees during periods of high demand. zkEVM, on the other hand, uses zero-knowledge proofs to improve scalability, but it is still in its early stages of development.

The ability of a platform to process a large number of transactions per second, known as transaction throughput, is a critical factor in assessing its scalability. High throughput is essential for maintaining fast and efficient operations, especially as the network grows, and the number of transactions increases.The transaction throughput is influenced by several factors, including the consensus mechanism, the cap on validators, and the limitations of EVM and zkEVM.

Scalability Considerations in Cosmos Hubs and Zones:

Cosmos, with its unique architecture of Hubs and Zones, offers a distinct approach to scalability. The Cosmos network is structured around a Hub, a blockchain that connects to multiple other blockchains known as Zones. This structure allows each Zone to operate independently, processing its transactions and maintaining a separate ledger, and can potentially offer significant scalability advantages, as each Zone can process transactions concurrently with others.

However, there are important considerations to bear in mind. The consensus mechanism of Cosmos, known as CometBFT, also limits the active validator set. According to the Cosmos documentation, the Cosmos Hub has 180 validators, (but it’s important to mention that over time the number of validators can be increased with governance proposals). The validators are determined by the total number of ATOM tokens delegated to them — the top 180 validator candidates with the most voting power are the current Cosmos validators.

Limited Validators: The cap on validators can have implications for both scalability and decentralization. Having a limited number of validators can make the consensus process more efficient, as fewer nodes need to communicate with each other to reach consensus. This can lead to faster transaction processing times, especially when the network is not heavily loaded.

This cap can limit the network's ability to scale. As the number of Zones and the volume of transactions increase, these validators may not be able to process transactions quickly enough to keep up with the demand. This could lead to network congestion, slower transaction processing times, and potentially higher transaction fees. Moreover, the cap on validators also has implications for the decentralization of the network. Fewer validators mean that control of the network is concentrated in fewer hands, which could lead to centralization. This could potentially make the network more vulnerable to attacks or manipulation by a small group of validators.

High Throughput: Cosmos uses the Inter-Blockchain Communication (IBC) protocol to allow different Zones to communicate with each other. This means that while you can have multiple Zones operating concurrently, there is a built-in mechanism for these Zones to communicate and share load. This could potentially lead to efficiencies and increased scalability as the network scales.

Since the Cosmos network is not solely EVM-based, it does not suffer from the same scalability issues as Ethereum. This also means that it may not be fully compatible with Ethereum's tooling and ecosystem, potentially creating additional challenges for developers. The ability of a platform to process a large number of transactions per second, known as transaction throughput, is a critical factor in assessing its scalability. High throughput is essential for maintaining fast and efficient operations, especially as the network grows and the number of transactions increases. With Cosmos, the transaction throughput is influenced by several factors, including the consensus mechanism, the cap on validators, and the use of the IBC protocol.

Scalability Considerations in Avalanche Subnets:

Avalanche employs a unique approach to scalability through the use of Subnets, which are essentially sub-networks within the larger Avalanche network. Each Subnet is a collection of validators working together to achieve consensus on the state of a set of blockchains. Each Subnet can have its own set of validators, and these validators can be a subset of the validators of the Avalanche network.

Unlimited Validators: Unlike some other blockchain networks, the Subnets in Avalanche are not limited by a cap on the number of validators. This allows for potentially unlimited scalability as the network can continue to grow with the addition of more validators. This is a significant advantage for large-scale applications that require high transaction throughput. The absence of a cap on validators not only enhances scalability but also promotes decentralization. With more validators, the control of the network is distributed among a larger group, reducing the risk of centralization and making the network more resilient to attacks or manipulation.

High Throughput: Avalanche employs a unique consensus protocol known as Avalanche Consensus, which allows for rapid finality of transactions and scales well as the network grows. This consensus protocol is highly efficient and enables high transaction throughput, further enhancing the scalability of the network. The ability of a platform to process a large number of transactions per second, known as transaction throughput, is a critical factor in assessing its scalability.

High throughput is essential for maintaining fast and efficient operations, especially as the network grows and the number of transactions increases. The transaction throughput is influenced by the consensus mechanism and the absence of a cap on validators. Avalanche's Subnet model also provides a high degree of flexibility and customization. Developers can create Subnets tailored to their specific needs, taking advantage of the best attributes from the initial Avalanche network. In addition to this, Avalanche's architecture allows for the creation of custom VMs. This means that developers can create VMs that are specifically designed to handle the requirements of their applications, further enhancing the scalability and efficiency of the network.

Customizability

In today’s rapidly evolving world, one size does not fit all. Different applications have different needs, and a blockchain network that works well for one use case may not be suitable for another. This is where the concept of customizability comes into play.

Blockchain customizability refers to the ability to tailor the network's features and functionalities to meet specific requirements. This can include aspects such as the consensus mechanism, the transaction validation process, the structure of the network, and even the programming language used for smart contracts. The ability to customize a blockchain network is crucial for developers and enterprises. It allows them to build solutions that are perfectly suited to their needs, rather than having to adapt their applications to fit the constraints of a pre-existing network. This can lead to more efficient, effective, and innovative solutions.

This adaptability hinges primarily on two factors:

1. Control Over Validator Sets: Developers should have the capacity to manage and regulate the validator sets. This includes the ability to decide whether the validation process is permissioned or permissionless, whether there are geographical restrictions or freedoms, and whether there are Know Your Customer (KYC) or Anti-Money Laundering (AML) compliance requirements. This level of control is vital as it directly influences the network's consensus mechanism, and consequently, its security and performance.

2. Technical Flexibility: Developers should have the freedom to construct any state machine or application as per their requirements. This encompasses the ability to create custom virtual machines, design unique smart contracts, gas token customization, and more. However, it's important to note that while this technical flexibility can drive innovation, it also requires a deep understanding of blockchain technology to ensure that the resulting applications are secure, efficient, and effective.

Customizability Considerations in Polygon Supernets:

Control Over Validator Sets: Polygon Supernets employ a consensus mechanism known as PolyBFT, which uses the Istanbul Byzantine Fault Tolerance (IBFT) 2.0 consensus engine. This engine is responsible for validating candidate blocks proposed by a randomly selected block proposer from the validator pool. The frequency of selection is proportional to the voting power of the validator. However, PolyBFT caps the number of validators at around 100 to maintain the system’s security and prevent it from becoming economically vulnerable. The validator set in PolyBFT does not update with each block but is fixed during block periods known as epochs. At the end of an epoch, a special state transaction is emitted to the validatorSetManagementContract, notifying the system about the validators’ uptime during the epoch. The smart contract then rewards validators based on their uptime and updates the validator set for the next epoch.

Technical Flexibility: In terms of technical freedom, Polygon Supernets only supports the Ethereum Virtual Machine (EVM). There have been discussions about integrating a variant of the zkEVM into Supernets, which would provide developers with a choice between the traditional EVM or the zkEVM. However, no projects have confirmed successful launches with this feature. This limitation could pose a significant constraint for developers interested in launching blockchains with custom virtual machines not specifically tied to the EVM.

Please note that the information provided here is based on the current state of Polygon Supernets and may change as the platform evolves. For the most accurate and up-to-date information, please refer to the official Polygon documentation and announcements.

Customizability Considerations in Cosmos Zones:

Control Over Validator Sets: Cosmos operates with a unique consensus mechanism known as Tendermint, which allows developers to have a significant degree of control over validator sets. Validators in Cosmos are chosen based on the amount of ATOM tokens they have staked, with the top 125 candidates by total voting power becoming validators. This process is not entirely permissionless, as it requires staking ATOM tokens and being among the top candidates in terms of total voting power. The number of validators can be increased through governance proposals, providing some flexibility in the network's consensus mechanism.

The Cosmos Hub operates with a designated set of validators, currently capped at 180, who shoulder the responsibility of committing new blocks to the blockchain. These validators engage in the consensus protocol by broadcasting cryptographically signed votes, authenticated with each validator's private key. The selection of validators is primarily based on the total delegation of ATOM tokens they receive, with the top 175 candidates, in terms of total voting power, becoming the active validators for the Cosmos Hub. Validators, along with their delegators, earn ATOM through block provisions and transaction fees. Validators have the discretion to set a commission rate on the fees their delegators receive. But, validators who engage in double signing or remain offline for an extended duration risk having their staked ATOM slashed, with the severity of the penalty contingent on the nature of the violation.

Technical Flexibility: Cosmos provides developers with a high degree of technical flexibility through the use of Cosmos SDK and the ability to create Cosmos Zones. The Cosmos SDK allows developers to build custom state machines and applications, with each module providing a specific piece of functionality. This could include account management, token transfers, or governance, among other things. Cosmos Zones, on the other hand, are independent blockchains that can be designed for specific purposes or applications, and they can communicate with each other by passing messages through Hubs.

Customizability Considerations in Avalanche Subnets:

Control Over Validator Sets: With Avalanche Subnets, developers have a high degree of control over their validator sets, allowing them to tailor the network to their specific needs. A Subnet is essentially a subset of validators, and developers can set any criteria they wish for validators to meet to participate in their network. This could range from creating a permissionless network where anyone can participate and validate transactions, to a permissioned network where only validators, who have undergone KYC (Know Your Customer) procedures, can participate and process transactions.

If a developer wants validators to be from certain geographical locations, Avalanche Subnets can accommodate this requirement. This level of customization and control is particularly beneficial for enterprises that need to operate their private blockchain network, providing them with the ability to set rules and parameters that best align with their business needs and regulatory requirements.

At the same time, it empowers individual developers to build open and distributed applications, fostering innovation and inclusivity in the blockchain space. This is possible due to the flexibility in Avalanche’s novel consensus protocol. Unlike other blockchain networks that have a fixed set of validators, Avalanche allows for the creation of multiple, dynamic validator sets (Subnets). Each Subnet operates its blockchain, or blockchains, and can have its own unique properties and validation rules. This design enables a high degree of customization and scalability.

Technical Flexibility: Avalanche provides developers with an unparalleled level of flexibility, enabling them to deploy virtually any application or virtual machine tailored to their specific use cases. This flexibility is largely due to Avalanche’s fluid consensus mechanism, which allows for the seamless integration of various virtual machines. Developers can launch their instances of a modified Ethereum Virtual Machine (EVM), or even deploy complete Layer 1 virtual machines such as MoveVM or SolanaVM. They can also create application-specific virtual machines - using tools like the HyperSDK or RustSDK to create VMs like a TokenVM for token operations, an IndexVM for indexing data, or a SocialMediaVM for social media applications.

Speed

Speed, particularly in terms of time to finality, is a crucial factor in the performance and usability of a blockchain network. Time to finality refers to the amount of time it takes for a transaction to be confirmed and finalized on the blockchain, meaning it cannot be reversed or altered. This metric is important because it directly impacts the user experience: the faster the time to finality, the quicker users can be confident that their transactions have been securely processed.

Speed also affects the scalability of a blockchain network. A network that can process transactions quickly is better equipped to handle larger volumes of transactions, which is a key aspect of scalability. A fast time to finality can enhance the security of a blockchain network. The quicker a transaction is finalized, the less opportunity there is for malicious actors to attempt to double-spend or otherwise manipulate the transaction.

Achieving a fast time to finality can be a complex task. It requires a well-designed consensus mechanism that can quickly and efficiently validate and finalize transactions, while also maintaining the security and decentralization of the network. Therefore, when evaluating a blockchain platform, it's important to consider not only its current time to finality but also how it plans to maintain or improve this metric as the network scales.

Speed in Polygon Supernets:

Polygon Supernets utilize the Istanbul Byzantine Fault Tolerance (IBFT) 2.0 consensus engine, which plays a crucial role in adding new blocks to the blockchain. The validator pool in IBFT 2.0 is responsible for validating candidate blocks proposed by a randomly selected block proposer who is part of the validator pool. The frequency of selection is proportional to the voting power of the validator. In an ideal scenario, the validator pool reaches consensus on a candidate block in the first round of voting, allowing the block to be added to the blockchain without the need for additional rounds of voting. This efficient process enables the network to continue processing transactions and adding new blocks to the chain promptly.

While the specific time to finality for Polygon Supernets is not explicitly mentioned, it's worth noting that the finality time for Polygon's Proof of Stake (PoS) system is approximately 2 seconds. Additionally, their Zero-Knowledge Ethereum Virtual Machine (zkEVM) has a finality of 2-3 seconds.

Speed in Cosmos Zones:

The Cosmos Network, including the Cosmos Hub and various Zones, are built on the Tendermint consensus algorithm. This algorithm is known for its fast finality, typically ranging from 1 to 6 seconds. This means that once a transaction is included in a block and that block is committed, the transaction is considered final and cannot be reversed. This is a significant improvement over many other blockchain networks, where finality can take minutes or even hours.

It's important to note that the finality time in Cosmos can vary depending on the specific configuration of each Zone or Hub. Factors that can influence finality time include the block time (i.e., the time it takes to create a new block) and the number of validators (i.e., the nodes that participate in the consensus process). A larger number of validators might increase the time it takes to reach consensus, while a shorter block time might decrease the finality time. In addition, while the Tendermint consensus algorithm offers fast finality in theory, practical considerations can introduce slight delays. Network latency, which is the delay caused by the time it takes for a data packet to travel from one point to another in the network, can affect the finality time. Other factors, such as hardware performance and network congestion, can also introduce delays. Therefore, while Cosmos offers fast finality times compared to many other blockchain networks, the actual finality time can vary depending on a variety of factors. It's always important to consider these factors when evaluating the performance of a blockchain network.

Speed in Avalanche Subnets:

Avalanche Subnets run an instance of the Avalanche consensus mechanism which is a novel approach to achieving consensus in a distributed network. It's designed to offer high scalability and speed, with a particular emphasis on achieving sub-second finality. The Avalanche consensus protocol operates on a principle of repeated sub-sampling and voting. In this process, a small, random subset of validators is sampled, and each validator in the sample votes on the state (or color) of a transaction. This process is repeated multiple times, with each validator updating its preference based on the votes it observes. Over time, the system converges towards a single color, achieving consensus. This repeated sub-sampling and voting process is what allows the Avalanche consensus protocol to achieve sub-second finality.

Because each round of voting brings the system closer to consensus, and because these rounds can be conducted very quickly, the system can confirm and finalize transactions in less than a second. This is a significant improvement over many other blockchain networks, which can take much longer to finalize transactions. The Avalanche consensus protocol also provides strong safety guarantees. It ensures that two correct nodes may make conflicting decisions, but with an infinitely small probability. This probabilistic safety guarantee allows Avalanche to provide a high degree of security while also maintaining fast transaction speeds and high scalability.

It's worth noting that while the Avalanche consensus protocol is effective, Avalanche recommends using the upgraded version of Avalanche consensus. Snowman++ is an optimized version of the Avalanche consensus protocol, designed to offer improved performance and efficiency. It maintains the same safety and liveness properties as the original Avalanche consensus but is more efficient in terms of computational and communication overhead.

Security

Security is a cornerstone of blockchain technology and plays a pivotal role in the performance and reliability of blockchain networks. It is the safeguard that ensures transactions are processed accurately, assets are stored securely, and the network remains resilient against potential threats. Without robust security measures, a blockchain network becomes vulnerable to a variety of attacks, such as double-spending, Sybil attacks, and 51% attacks, which can lead to significant losses and undermine the network's credibility. In the context of our discussion on scalability, customizability, and speed, security takes on an even more critical role.

As blockchain networks scale to handle larger volumes of transactions, they must also enhance their security measures to protect against increased threats. Similarly, as networks offer greater customizability and technical flexibility, they must ensure that these features do not compromise the network's security. Lastly, as networks strive to achieve faster transaction speeds and lower times to finality, they must also maintain robust security to prevent attacks that could exploit these efficiencies. Security in a blockchain network is achieved through a combination of cryptographic techniques, consensus mechanisms, and network architecture.

Cryptographic techniques, such as hashing and digital signatures, ensure the integrity and non-repudiation of transactions. Consensus mechanisms, like the PolyBFT in Polygon Supernets, the Tendermint-based consensus in Cosmos, or the Snow consensus protocol in Avalanche, ensure that all nodes in the network agree on the state of the blockchain. Network architecture, including the use of peer-to-peer networks and decentralization, helps to prevent single points of failure and increases the resilience of the network.

Achieving a high level of security is not a static task. It requires ongoing vigilance, regular updates, and continuous improvements to stay ahead of potential threats. As the blockchain ecosystem continues to evolve and grow, so too do the potential security risks. Therefore, when evaluating a blockchain platform, it's important to consider not only its current security measures but also how it plans to maintain and enhance its security in the future. This is particularly relevant when considering the trade-offs between scalability, customizability, speed, and security in different blockchain platforms.

Security in Polygon Supernets:

Polygon Supernets employ Polygon Byzantine Fault Tolerance (PolyBFT) which is composed of two key components: a consensus engine and a consensus protocol. PolyBFT leverages the Istanbul Byzantine Fault Tolerance (IBFT 2.0) consensus engine and a Proof-of-Stake architecture to seal blocks, provide network capabilities, and govern the network. The core smart contracts work in conjunction with the consensus engine to define all the network's Proof-of-Stake rules.

The IBFT 2.0 protocol, which forms the basis of the PolyBFT consensus engine, is responsible for sealing blocks on the blockchain. This protocol ensures the integrity of the network even in the presence of malicious or dishonest nodes. To achieve fault tolerance, IBFT allows for f faulty nodes in a 3f + 1 network, as long as two-thirds of the nodes are honest. This algorithm is also known as a "super-majority rules'' algorithm. The PolyBFT consensus protocol is implemented through a set of core smart contracts. These contracts serve multiple purposes, including enabling staking functionality, defining an incentivization scheme for validators on the network, managing the validator set, and facilitating cross-chain communication through a native bridge.

The bridge is a critical component of the network's interoperability, transferring assets and data between a Supernet and an external EVM-compatible blockchain (root chain). Two predicate contracts, one on the Supernet and one on the rootchain, implement the core bridge functionality and use the associated core contracts to deposit, withdraw, and verify cross-chain bridge transactions. In terms of security, the PolyBFT consensus mechanism, coupled with the Proof-of-Stake architecture and the use of core smart contracts, provides a robust framework for maintaining the integrity and security of the Polygon Supernets. The use of a super-majority rules algorithm in the consensus protocol, further enhances the network's resilience against malicious activities.

The security of Polygon Supernets is dependent on the behavior of its validators. The capped number of validators (around 100) in the PolyBFT mechanism is a measure to maintain the system's security and prevent it from becoming economically vulnerable. Butthis also means that the security of the network is concentrated in these validators, making the network potentially more susceptible to collusion or malicious activities by a small number of validators. While Polygon Supernets have robust security measures in place, like any other blockchain network, they are not immune to potential security risks. Therefore, users and developers must understand these risks and consider them when choosing to build on or use Polygon Supernets.

Security in Cosmos Zones and Hubs:

Cosmos, with its unique architecture of Hubs and Zones, has implemented a variety of security measures to ensure the safety and integrity of its network. The Cosmos Hub, which is the first hub in the Cosmos Network, is secured by a set of validators that are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes that contain cryptographic signatures signed by each validator’s private key.

Validator candidates can bond their ATOM and have ATOM delegated to them by token holders. The Cosmos Hub has a set number of validators (currently 175), but over time the number of validators can be increased with governance proposals. Validators are determined by the total number of ATOM tokens delegated to them. The top 175 validator candidates with the most voting power are the current Cosmos validators.

Validators and their delegators earn ATOM as block provisions and tokens as transaction fees through the execution of the Tendermint consensus protocol. Validators can set a commission percentage on the fees their delegators receive as an additional incentive. If validators double sign or are offline for an extended period, their staked ATOM (including ATOM of users that delegated to them) can be slashed. The penalty depends on the severity of the violation.

In terms of technical security, Cosmos uses the CometBFT consensus engine, a state replication engine designed for the interchain ecosystem. This consensus engine provides a high degree of security and reliability, ensuring that all transactions are accurately replicated across the network.

Shared Security, also known as Interchain Security, is a feature in development within the Cosmos network that aims to bolster the security of individual chains or "zones". The concept revolves around the idea that multiple chains within the Cosmos network can pool their security resources. Newer or smaller chains can benefit from the security provided by the validators of more established chains like the Cosmos Hub.

This is achieved through a shared security model where individual zones can connect to the Cosmos Hub and utilize its validators and staking tokens to secure their own chains. A shared security model can significantly enhance the overall security of individual zones by leveraging the established security resources of the Cosmos Hub. However, it also introduces potential risks.

If a large number of zones are connected to the Cosmos Hub and rely heavily on its validators and staking tokens, it could create a central point of failure. This centralization could potentially be exploited by malicious actors, thereby posing a risk to the entire network. Moreover, the security of individual zones can vary based on their implementation and validator set. Zones with a small or centralized set of validators may be more susceptible to attacks, even with Shared Security in place.

It's important to note that Shared Security is still a feature in development within the Cosmos network, and its implementation may evolve over time. For the most accurate and up-to-date information, please refer to the official Cosmos documentation.

Security in Avalanche Subnets:

This protocol is designed to provide robust security while maintaining high performance and scalability. Avalanche Consensus employs a probabilistic safety model, which means that while it's theoretically possible for a conflicting decision to be made, the probability of such an event is infinitesimally small. This model allows Avalanche to provide a high degree of security while maintaining fast transaction speeds and high scalability.

The security model is further enhanced by the ability to customize the validator set. Developers can specify any criteria they wish for validators to meet in order to participate in their network. This could include KYC/AML checks, geographic restrictions, or other requirements. This flexibility allows developers to tailor the security model of their Subnet to their specific needs. Each Subnet in Avalanche operates its own blockchain, or blockchains, and can have its own unique properties and validation rules. This design enables a high degree of customization and scalability, while also providing isolation between Subnets.

If one Subnet were to be compromised, the impact would be contained within that Subnet and would not affect the rest of the Avalanche network. It's important to note that while Avalanche provides these robust security features, the security of individual Subnets ultimately depends on their specific implementation and validator set. Developers need to carefully consider their security requirements and design their Subnet accordingly.

Conclusion

The advent of scalability solutions like Polygon Supernets, Cosmos, and Avalanche Subnets is reshaping the way we perceive scalability, customizability, and security in the blockchain sphere. These platforms bring unique strengths to the table, offering a diverse array of solutions for developers and enterprises alike. Polygon Supernets, with their PolyBFT consensus mechanism, provide a robust platform for developers, particularly those already familiar with the Ethereum ecosystem. The integration of the Ethereum Virtual Machine (EVM) offers a familiar environment for developers to build upon. However, the platform’s scalability and customizability are somewhat constrained by the fixed validator set and the lack of support for custom virtual machines beyond the EVM.

Cosmos introduces a novel approach to blockchain architecture with its Hub and Zone model. This design offers a high degree of scalability and customizability, allowing developers to create application-specific blockchains that can interoperate seamlessly. The planned implementation of Shared Security or Interchain Security promises to enhance the security of individual zones, although the security of each zone can still vary based on its specific implementation and validator set. Cosmos stands as a beacon of innovation in the blockchain space, pushing the boundaries of what’s possible with blockchain technology.

Avalanche distinguishes itself with its Subnets, which offer strong customizability and scalability. Developers can specify custom validator sets and deploy virtually any application or virtual machine, opening up a world of possibilities for blockchain development. Coupled with Avalanche’s consensus protocol, which provides sub-second finality times and robust security, Avalanche Subnets represent a significant leap forward in blockchain technology.

The security of individual Subnets depends on their specific implementation, underscoring the importance of careful planning and design. The choice between these platforms will hinge on the specific needs and objectives of the developers and the use case at hand. Each platform offers unique advantages and potential challenges, underscoring the importance of careful evaluation and consideration.

As we continue to witness the evolution and maturation of these platforms, we can anticipate a future filled with even more innovative solutions and applications in the blockchain space. The journey of blockchain technology is just beginning, and platforms like Polygon Supernets, Cosmos, and Avalanche are paving the way towards a future where blockchain technology is an integral part of our digital lives.

Written by Usman Asim

From Snowflake to Avalanche through consensus to the stars.

Getting Started Building on Avalanche

Avalanche is an open-source platform for building decentralized applications in one interoperable, highly scalable ecosystem. It is the first ecosystem designed to accommodate the scale of global finance, with near-instant transaction finality. That means that after issuing a transaction to the network it will be included in the chain within about two seconds and is immutable from there on. Ethereum has a finality of about 15 minutes and Bitcoin has a finality of about one hour.

Avalanche is a global financial network for the issuing and trading of all digital goods. The Avalanche network enables potentially millions of validators to process thousands of transactions per second using a protocol which is completely green and quiescent. This high-throughput and fast finality protocol has been paired with an architecture that can meet the needs of unique financial services and decentralized apps.

This is accomplished through the notion of Subnets. Subnets allow anyone, anywhere to spin up a taylor-made network with custom virtual machines and complex validator rulesets. Avalanche is a network of networks. It’s a platform of platforms where we invision thousands and thousands of public and private Subnets all emerging into this global marketplace which we call The Internet of Finance.

Unique Features

Avalanche has 3 unique features which set it apart from competitors. Consensus, Virtual Machines and Subnets.

Consensus is the process of getting a set of computers to agree on something and it’s a rich field of computer science dating back 40 years. Avalanche Consensus represents the 3rd major paradigm in the field of consensus and is a metastable consensus protocol inspired by epidemic protocols and gossip networks. Avalanche Consensus enables tens of thousands of transactions per second, with sub-second immutable and irreversible finality validated by potentially millions of validators globally. Here is an Avalanche Consensus Demo created by Ava Labs’ Ted Yin.

A Virtual Machine is the blueprint for a custom blockchain on the Avalanche network. VMs contain the application-level logic for your blockchain and are akin to a class in object-oriented programming. A VM can be instantiated into many different instances of blockchains — each completely independent and with it’s own state. VMs aren’t limited to existing blockchain tech use cases such as P2P payments or defi and can be any use case which requires decentralization and consensus. VMs can be implemented in any language which can implement a GRPC API which enables developers to leverage modern tools and workflows which they’re familiar with.

A Subnet is a dynamic set of Validators working together to achieve consensus on the state of a set of blockchains. Subnets can compose their constituent validator sets via powerful rulesets. Subnets can be permissioned or permissionless — public or private. Subnets are used for scaling by enabling developers to launch application-specific-blockchains on different Subnets as opposed to many apps sharing the same blockchain. Subnets can communicate via Avalanche Warp Messaging.

Consensus

As previously mentioned, Avalanche Consensus is the 3rd major paradigm in the field of consensus. The first was called Classical Consensus and it goes back to the 80s. Classical Consensus has low latency and very high throughput. It’s lightweight and green. However it isn’t very scalable nor robust and it performs poorly in adversarial conditions.

In 2008/2009 when Satoshi Nakamoto released Bitcoin the world was introduced to the 2nd major paradigm in the field of consensus, what ultimately became known as Nakamoto Consensus. Nakamoto Consensus is very scalable, robust and decentralized but it doesn’t have low latency, it takes around an hour to be sure your transaction is sufficiently settled that you won’t experience a reorg. It doesn’t have high throughput, Bitcoin only does a handful of transaction per second. It’s not lightweight or green, Bitcoin burns more energy each day than some nation states. Lastly, Nakamoto Consensus performs ok in adversarial conditions up to the famous 51% attack.

In 2018 a pseudonymous group going by the name “Team Rocket” released a white paper on the InterPlanetary File System (IPFS) describing a 3rd major paradigm shift in the field of consensus. This new breakthrough was known as Avalanche Consensus. Avalanche Consensus is the perfect storm of features from Classical and Nakamoto Consensus.

It’s very scalable, robust and decentralized. There are currently around 1500 full block and vertex producing validators on the Avalanche network. The protocol theoretically enables millions of validators so it’s very decentralized. Avalanche consensus has low latency with subsecond immutable and irreversible finality. There is no notion of a reorg on Avalanche. Within a literal blink of an eye your transaction has settled completely. Avalanche has high throughput with 10s of thousands of transactions per second. It’s very lightweight and green and can be run on a PC, a Macbook, a VPS droplet on the cloud and in the future on Internet of Things devices. And Avalanche consensus is parameterizable so it performs very well in adversarial conditions.

Virtual Machines

Traditional blockchain networks, such as Bitcoin and Ethereum, consist of a single virtual machine and set of validators. Avalanche is a network of many different virtual machines all deployed on Subnets and communicating with each other as needed. This architecture leads to network effects on the individual blockchains and compound network effects between subnets and blockchains.

A Virtual Machine is a state machine. It specifies the blockchain’s state, state transition function, transactions, and the API through which users can interact with the blockchain. Every blockchain on Avalanche is an instance of a VM.

The way to think of a VM is like a class in OOP. A class is a description or an object. It’s a template from which you can instantiate as many objects as you wish. Each of these objects, though derived from a common template, are unique and logically separate entities with their own state. Similar to a class, a VM is a blueprint or template from which you can instantiate as many different instances of a blockchain as you wish. Each of these blockchains, though derived from a common template, are unique and logically separate entities with their own state.

As a developer when you write a VM, you don’t need to concern yourself with lower-level logic like networking, consensus, or the structure of the blockchain. Avalanche does this behind the scenes so you can focus on the thing you would like to build.

On Avalanche you can build your VM in any language that you choose. To see examples of existing Virtual Machines check out:

Golang

• Coreth An implementation of the EVM that powers the Avalanche C-Chain that supports Solidity smart contracts.
• Subnet-EVM An implementation of the EVM that can be deployed to a custom Subnet to support Solidity smart contracts
• SpacesVM An authenticated, hierarchical key-value store w/EIP-712 compatibility, state expiry, and fee-based metering
• BlobVM A content-addressable key-value store w/EIP-712 compatibility and fee-based metering
• TimestampVM A decentralized timestamp server
• XSVM An example of Avalanche Warp Messaging that implements Cross-Subnet asset transfers

Rust

The following VMs were built using Rust via the Avalanche Rust SDK

• TimestampVM RS A Rust implementation of TimestampVM
• SpacesVM RS A Rust implementation of SpacesVM

For more information on building VMs check out:

• How to Build a Simple Golang VM
• How to Build a Complex Golang VM
• How to Build a Simple Rust VM

Subnets

A Subnet is a sovereign network which defines its own rules regarding its membership and token economics. Subnets are independent, they specify their own execution logic, determine their own fee regime, maintain their own state, facilitate their own networking, and provide their own security. They don’t share execution thread, storage or networking with other Subnets including the Primary Network, effectively allowing the network to scale up easily while enabling lower latency, higher transactions per second (TPS), and lower transaction costs provided by the Avalanche Consensus.

A Subnet manages its own membership, it can create its own token economics and rules, and may require that its constituent validators have certain properties.

Independent Token Economics

Subnets can have their own token economics with their own native tokens and fee markets. They can launch their own blockchains with customized virtual machines.

Compliance

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 given country
• Validators must pass a KYC/AML checks
• Validators must hold a certain license

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 could require that validators meet certain hardware requirements so that the application doesn’t suffer from low performance due to slow validators.

Support for Private Blockchains

You can create a Subnet where only certain pre-defined validators may join and create a private Subnet where the contents of the blockchains would be visible only to those validators. This is ideal for organizations interested in keeping their information private. See here for more info.

Separation of Concerns

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 concern themselves with blockchains that they care about. This reduces the burden on validators.

Tools and Resources

Following is a list of tools and resources to help developers onramp onto the Avalanche Platform. This should include running a node, sending it queries, SDKs for sending transactions, creating virtual machines and Subnets and the associated documentation.

Avalanche Docs

Here are the official Avalanche docs. These are the canonical Avalanche platform docs.

AvalancheGo

AvalancheGo is a full Avalanche node. It’s written in Golang and required for running local networks for development or for running a node and connecting to the Fuji testnet or the mainnet.

The minimum recommended hardware specification for nodes connected to Mainnet is:

• CPU: Equivalent of 8 AWS vCPU
• RAM: 16 GiB
• Storage: 1 TiB
• OS: Ubuntu 20.04/22.04 or macOS >= 12
• Network: Reliable IPv4 or IPv6 network connection, with an open public port.

Binary Install

Download the latest build for your operating system and architecture. The Avalanche binary to be executed is named avalanchego.

You can also build from source, install with apt and install with docker.

Connect to the Network

./path/to/avalanchego --http-host=my.http.host --network-id=fuji --public-ip=my.ip.address

By default avalanchego will connect to the mainnet which will require significantly more time to bootstrap than the fuji network. Configure which network the node should bootstrap by passing in the --network-id flag. You can get funds for the Testnet from the faucet.

To be able to make API calls to your node from other machines, when starting up the node include the --http-host= flag. In order to ensure your node is well-connected, make sure that your node can receive and send TCP traffic on the staking port (9651 by default) and that you started your node with config flag --public-ip=[YOUR NODE'S PUBLIC IP HERE]. Failing to do either of these may jeopardize your staking reward.

Starting a full node this way is fine if you’re doing short-term experimental work. For instances where you intend to keep your node online for longer you should set up a system service. The installer script can do that for you.

AvalancheGo is a core software component needed for developing dapps and VMs for Avalanche. It’s required for running an individual node and a local test network. More info: Github Repo.

Avalanche Network Runner

While AvalancheGo is useful for running a single node the Avalanche Network Runner (ANR) is a tool to run and interact with a local Avalanche network and is especially useful for development and testing.

Installation

To download a binary for the latest release, run:

curl -sSfL <https://raw.githubusercontent.com/ava-labs/avalanche-network-runner/main/scripts/install.sh> | sh -s

The binary will be installed inside the ~/bin directory. To add the binary to your path, run

export PATH=~/bin:$PATH

To add it to your path permanently, add an export command to your shell initialization script (ex: .bashrc or .zshrc). You can also build from source.

Run a 5 Node Local Network

The easiest way to run a local network with the ANR is to use the example script to fire up a 5 node network.

git clone <https://github.com/ava-labs/avalanche-network-runner.git>
cd avalanche-network-runner
go run examples/local/fivenodenetwork/main.go

[03-29|18:18:35.873] INFO fivenodenetwork/main.go:93 waiting for all nodes to report healthy...
[03-29|18:18:35.873] INFO local/network.go:631 checking local network healthiness {"num-of-nodes": 5}
[03-29|18:18:44.886] INFO fivenodenetwork/main.go:98 All nodes healthy. Network will run until you CTRL + C to exit...

You can now send curl requests to the nodes on localhost

curl --location '<http://127.0.0.1:9650/ext/info>' \\
--header 'Content-Type: application/json' \\
--data '{
    "jsonrpc":"2.0",
    "id"     :1,
    "method" :"info.isBootstrapped",
    "params": {
        "chain": "X"
    }
}'

{
    "jsonrpc": "2.0",
    "result": {
        "isBootstrapped": true
    },
    "id": 1
}

More info on the ANR Github Repo.

AvalancheCLI

The Avalanche Network Runner is very helpful for launching a local network running the primary Subnet. This is great for interacting with the X, P or C-chains. However, if you want to deploy and test Subnets then you want to use AvalancheCli. Avalanche CLI is a command line tool that gives developers access to everything Avalanche. This release specializes in helping developers develop and test subnets.

Installation

The tool has been tested on Linux and Mac. Windows is currently not supported. To download a binary for the latest release, run:

curl -sSfL <https://raw.githubusercontent.com/ava-labs/avalanche-cli/main/scripts/install.sh> | sh -s

The binary will be installed inside the ~/bin directory.

To add the binary to your path, run

export PATH=~/bin:$PATH

To add it to your path permanently, add an export command to your shell initialization script (ex: .bashrc or .zshrc).

You can also build locally or install via docker.

Quickstart

After installing, launch your own custom subnet:

avalanche subnet create <subnetName>
avalanche subnet deploy <subnetName>

Shut down your local deployment with:

avalanche network stop

Restart your local deployment (from where you left off) with:

avalanche network start

More info on AvalancheCli in the Github Repo.

AvalancheJS

AvalancheJS is a JavaScript Library for interfacing with the Avalanche Platform. It is built using TypeScript and intended to support both browser and Node.js. The AvalancheJS library allows you to issue commands to the Avalanche node APIs.

The APIs currently supported by default are:

• Admin API
• Auth API
• AVM API (X-Chain)
• EVM API (C-Chain)
• Health API
• Index API
• Info API
• Keystore API
• Metrics API
• PlatformVM API (P-Chain)
• Socket

Installation

Avalanche is available for install via yarn:

yarn add avalanche

You can also pull the repo down directly and build it from scratch:

yarn build

Examples

AvalancheJS has dozens of example scripts in the examples/ directory.

ts-node examples/info/isBootstrapped.ts
true

More info on AvalancheJS in the Github Repo

Glacier

The Glacier API is a developer’s one-stop-shop for all enriched blockchain data from Avalanche and Ethereum and the official API service indexing Avalanche Subnets.

The Glacier API Beta gives developers a wide range of useful data for explorer and wallet services, token transfers and more. Originally created to power the Avalanche Subnet Block Explorer, Glacier also powers Core Wallet — providing balances, transfers, and associated metadata for native assets, ERC-20 tokens and NFTs.

With Glacier, application developers can easily build products that leverage real-time and historical transaction data — all served through highly performant APIs. Developers that join the Glacier API Beta will get access to the platform’s service for free and have the opportunity to shape future feature development.

Glacier’s capabilities as a powerful indexed blockchain data provider will expand to include additional raw and derived transaction data as user feedback helps guide this process.

There is a public Swagger UI for quickly testing out the Glacier API and customizing requests POST body and copying curl statements for easily sharing requests.

For example, first let’s GET the list of chains supported by the api. At the time of writing is 14 chains including the following:

• Avalanche C-Chain (Fuji and Mainnet)
• Ethereum
• DFK Subnet (Fuji and Mainnet)
• Swimmer Network Subnet (Fuji and Mainnet)
• Dexalot Subnet (Fuji and Mainnet)
• Loco Legends Subnet (Fuji and Mainnet)
• D-Chain
• WAGMI Subnet
• Green Dot Subnet

Request

/v1/chains

curl -X 'GET' \\
  '<https://glacier-api.avax.network/v1/chains>' \\
  -H 'accept: application/json'

Response

NOTE that the response is truncated after one chains object.

{
  "chains": [
    {
      "chainId": "43114",
      "chainName": "Avalanche (C-Chain)",
      "description": "The Contract Chain (C-Chain) runs on an Ethereum Virtual Machine and is used to deploy smart contracts and connect to dapps.",
      "platformChainId": "2q9e4r6Mu3U68nU1fYjgbR6JvwrRx36CohpAX5UQxse55x1Q5",
      "subnetId": "11111111111111111111111111111111LpoYY",
      "vmId": "mgj786NP7uDwBCcq6YwThhaN8FLyybkCa4zBWTQbNgmK6k9A6",
      "vmName": "EVM",
      "explorerUrl": "<https://snowtrace.io>",
      "rpcUrl": "<https://api.avax.network/ext/bc/C/rpc>",
      "wsUrl": "wss://api.avax.network/ext/bc/C/ws",
      "isTestnet": false,
      "utilityAddresses": {
        "multicall": "0xed386Fe855C1EFf2f843B910923Dd8846E45C5A4"
      },
      "networkToken": {
        "name": "Avalanche",
        "symbol": "AVAX",
        "decimals": 18,
        "description": "",
        "logoUri": "<https://glacier-api.avax.network/proxy/chain-assets/cb14a1f/chains/43114/token-logo.png>"
      },
      "chainLogoUri": "<https://glacier-api.avax.network/proxy/chain-assets/cb14a1f/chains/43114/chain-logo.png>"
    },
    ...
}

Next let’s take that returned chainId and get the latest blocks indexed for that chain.

Request

/v1/chains/{chainId}/blocks?pageSize=&pageToken=

NOTE that this request has 1 URL required URL parameter and 2 optional query string parameters.

• chainId string (path): A supported evm chain id. Use the /chains endpoint to get a list of supported chain ids.
• pageSize integer (query): The maximum number of items to return. The minimum page size is 1. The maximum pageSize is 100.
• pageToken string (query): A page token, received from a previous list call. Provide this to retrieve the subsequent page.

curl -X 'GET' \\
  '<https://glacier-api.avax.network/v1/chains/43114/blocks?pageSize=10>' \\
  -H 'accept: application/json'

Response

NOTE that the response is truncated after one blocks object.

{
  "blocks": [
    {
      "blockNumber": "27398610",
      "blockTimestamp": 1678738466,
      "blockHash": "0x15a9fa15115f43f41844a718ded08e959a237dc6168fdb29736489edded081bc",
      "txCount": 9,
      "atomicTxCount": 0,
      "baseFee": "25000000000",
      "gasUsed": "6544183",
      "gasLimit": "8000000",
      "gasCost": "400000",
      "parentHash": "0xf152746ab4aea61d8db992a1953e3d379633eaaac4291d29b56cf957f8be64e3",
      "feesSpent": "173650909164332187",
      "cumulativeTransactions": "222464194"
    },
    ...
  ],
  "nextPageToken": "eyJzayI6eyJTIjoiMDAwMDAwMDAwMWEyMTFiZiJ9LCJpc0Jsb2NrIjp7Ik4iOiIxIn0sInBrIjp7IlMiOiJCIzB4OGRhYjQwZTAxMDFhZTdkNzJhNmQyYjE1M2Q0ZWI5NWE4MDQyOGZjMzcwYmYwYzgyZjFkMjczM2M5NTI1NGM1YSJ9LCJibG9ja1NrIjp7IlMiOiJCIzAwMDAwMDAwMDFhMjExYmYifX0"
}

Postman Collection

Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle. The Avalanche Postman collection supports the full JSON RPC.

Installation

1. Download Postman
2. Import Avalanche Postman Collection. Import -> Upload Files -> Avalanche.postman_collection.json
3. Import the Example Avalanche Postman Environment. Settings -> Import -> Choose Files -> Example_Avalanche_Environment.postman_environment.json
4. Call any Avalanche RPC endpoint

Usage

curl --location '<https://api.avax.network/ext/info>' \\
--header 'Content-Type: application/json' \\
--data '{
   "jsonrpc":"2.0",
   "id"     :1,
   "method" :"info.isBootstrapped",
   "params": {
       "chain": "X"
   }
}'

{
   "jsonrpc": "2.0",
   "result": {
       "isBootstrapped": true
   },
   "id": 1
}

Github Repo

~Written by Gabriel Cardona

Introduction to Avalanche: Kicking of the new Avax Developers Blog Series was originally published in Avalanche on Medium, where people are continuing the conversation by highlighting and responding to this story.