README.md

ACP	77
Title	Reinventing Subnets
Author(s)	Dhruba Basu (@dhrubabasu)
Status	Implementable (Discussion)
Track	Standards
Replaces	ACP-13

Abstract

Overhaul Subnet creation and management to unlock increased flexibility for Subnet creators by:

• Separating Subnet validators from Primary Network validators (Primary Network Partial Sync, Removal of 2000 $AVAX requirement)
• Moving ownership of Subnet validator set management from P-Chain to Subnets (ERC-20/ERC-721/Arbitrary Staking, Staking Reward Management)
• Introducing a continuous P-Chain fee mechanism for Subnet validators (Continuous Subnet Staking)

This ACP supersedes ACP-13 and borrows some of its language.

Motivation

Each node operator must stake at least 2000 $AVAX ($70k at time of writing) to first become a Primary Network validator before they qualify to become a Subnet validator. Most Subnets aim to launch with at least 8 Subnet validators, which requires staking 16000 $AVAX ($560k at time of writing). All Subnet validators, to satisfy their role as Primary Network validators, must also allocate 8 AWS vCPU, 16 GB RAM, and 1 TB storage to sync the entire Primary Network (X-Chain, P-Chain, and C-Chain) and participate in its consensus, in addition to whatever resources are required for each Subnet they are validating.

Regulated entities that are prohibited from validating permissionless, smart contract-enabled blockchains (like the C-Chain) cannot launch a Subnet because they cannot opt-out of Primary Network Validation. This deployment blocker prevents a large cohort of Real World Asset (RWA) issuers from bringing unique, valuable tokens to the Avalanche Ecosystem (that could move between C-Chain <> Subnets using Avalanche Warp Messaging/Teleporter).

A widely validated Subnet that is not properly metered could destabilize the Primary Network if usage spikes unexpectedly. Underprovisioned Primary Network validators running such a Subnet may exit with an OOM exception, see degraded disk performance, or find it difficult to allocate CPU time to P/X/C-Chain validation. The inverse also holds for Subnets with the Primary Network (where some undefined behavior could bring a Subnet offline).

Although the fee paid to the Primary Network to operate a Subnet does not go up with the amount of activity on the Subnet, the fixed, upfront cost of setting up a Subnet validator on the Primary Network deters new projects that prefer smaller, even variable, costs until demand is observed. Unlike L2s that pay some increasing fee (usually denominated in units per transaction byte) to an external chain for data availability and security as activity scales, Subnets provide their own security/data availability and the only cost operators must pay from processing more activity is the hardware cost of supporting additional load.

Elastic Subnets, introduced in Banff, enabled Subnet creators to activate Proof-of-Stake validation and uptime-based rewards using their own token. However, this token is required to be an ANT (created on the X-Chain) and locked on the P-Chain. All staking rewards were distributed on the P-Chain with the reward curve being defined in the TransformSubnetTx and, once set, was unable to be modified.

With no Elastic Subnets live on Mainnet, it is clear that Permissionless Subnets as they stand today could be more desirable. There are many successful Permissioned Subnets in production but many Subnet creators have raised the above as points of concern. In summary, the Avalanche community could benefit from a more flexible and affordable mechanism to launch Permissionless Subnets.

A Note on Nomenclature

Avalanche Subnets are subnetworks validated by a subset of the Primary Network validator set. The new network creation flow outlined in this ACP does not require any intersection between the new network's validator set and the Primary Network's validator set. Moreover, the new networks have greater functionality and sovereignty than Subnets. To distinguish between these two kinds of networks, the community has been referring to these new networks as Avalanche Layer 1s, or L1s for short.

All networks created through the old network creation flow will continue to be referred to as Avalanche Subnets.

Specification

At a high-level, L1s can manage their validator sets externally to the P-Chain by setting the blockchain ID and address of their validator manager. The P-Chain will consume Warp messages that modify the L1's validator set. To confirm modification of the L1's validator set, the P-Chain will also produce Warp messages. L1 validators are not required to validate the Primary Network, and do not have the same 2000 $AVAX stake requirement that Subnet validators have. To maintain an active L1 validator, a continuous fee denominated in $AVAX is assessed. L1 validators are only required to sync the P-Chain (not X/C-Chain) in order to track validator set changes and support cross-L1 communication.

P-Chain Warp Message Payloads

To enable management of an L1's validator set externally to the P-Chain, Warp message verification will be added to the PlatformVM. For a Warp message to be considered valid by the P-Chain, at least 67% of the sourceChainID's weight must have participated in the aggregate BLS signature. This is equivalent to the threshold set for the C-Chain. A future ACP may be proposed to support modification of this threshold on a per-L1 basis.

For messages produced by the P-Chain for a given L1, only that L1's validators must be willing to provide signatures, rather than the entire Primary Network validator set. This optimization is possible because all validators will still sync the P-Chain.

The following Warp message payloads are introduced on the P-Chain:

• SubnetToL1ConversionMessage
• RegisterL1ValidatorMessage
• L1ValidatorRegistrationMessage
• L1ValidatorWeightMessage

The method of requesting signatures for these messages is left unspecified. A viable option for supporting this functionality is laid out in ACP-118 with the SignatureRequest message.

All node IDs contained within the message specifications are represented as variable length arrays such that they can support new node IDs types should the P-Chain add support for them in the future.

The serialization of each of these messages is as follows.

SubnetToL1ConversionMessage

The P-Chain can produce a SubnetToL1ConversionMessage for consumers (i.e. validator managers) to be aware of the initial validator set.

The following serialization is defined as the ValidatorData:

Field	Type	Size
nodeID	[]byte	4 + len(nodeID) bytes
blsPublicKey	[48]byte	48 bytes
weight	uint64	8 bytes
		60 + len(nodeID) bytes

The following serialization is defined as the ConversionData:

Field	Type	Size
codecID	uint16	2 bytes
subnetID	[32]byte	32 bytes
managerChainID	[32]byte	32 bytes
managerAddress	[]byte	4 + len(managerAddress) bytes
validators	[]ValidatorData	4 + sum(validatorLengths) bytes
		74 + len(managerAddress) + sum(validatorLengths) bytes

• codecID is the codec version used to serialize the payload, and is hardcoded to 0x0000
• sum(validatorLengths) is the sum of the lengths of ValidatorData serializations included in validators.
• subnetID identifies the Subnet that is being converted to an L1 (described further below).
• managerChainID and managerAddress identify the validator manager for the newly created L1. This is the (blockchain ID, address) tuple allowed to send Warp messages to modify the L1's validator set.
• validators are the initial continuous-fee-paying validators for the given L1.

The SubnetToL1ConversionMessage is specified as an AddressedCall with sourceChainID set to the P-Chain ID, the sourceAddress set to an empty byte array, and a payload of:

Field	Type	Size
codecID	uint16	2 bytes
typeID	uint32	4 bytes
conversionID	[32]byte	32 bytes
		38 bytes

• codecID is the codec version used to serialize the payload, and is hardcoded to 0x0000
• typeID is the payload type identifier and is 0x00000000 for this message
• conversionID is the SHA256 hash of the ConversionData from a given ConvertSubnetToL1Tx

RegisterL1ValidatorMessage

The P-Chain can consume a RegisterL1ValidatorMessage from validator managers through a RegisterL1ValidatorTx to register an addition to the L1's validator set.

The following is the serialization of a PChainOwner:

Field	Type	Size
threshold	uint32	4 bytes
addresses	[][20]byte	4 + len(addresses) * 20 bytes
		8 + len(addresses) * 20 bytes

• threshold is the number of addresses that must provide a signature for the PChainOwner to authorize an action.
• Validation criteria:
  • If threshold is 0, addresses must be empty
  • threshold <= len(addresses)
  • Entries of addresses must be unique and sorted in ascending order

The RegisterL1ValidatorMessage is specified as an AddressedCall with a payload of:

Field	Type	Size
codecID	uint16	2 bytes
typeID	uint32	4 bytes
subnetID	[32]byte	32 bytes
nodeID	[]byte	4 + len(nodeID) bytes
blsPublicKey	[48]byte	48 bytes
expiry	uint64	8 bytes
remainingBalanceOwner	PChainOwner	8 + len(addresses) * 20 bytes
disableOwner	PChainOwner	8 + len(addresses) * 20 bytes
weight	uint64	8 bytes
		122 + len(nodeID) + (len(addresses1) + len(addresses2)) * 20 bytes

• codecID is the codec version used to serialize the payload, and is hardcoded to 0x0000
• typeID is the payload type identifier and is 0x00000001 for this payload
• subnetID, nodeID, weight, and blsPublicKey are for the validator being added
• expiry is the time at which this message becomes invalid. As of a P-Chain timestamp >= expiry, this Avalanche Warp Message can no longer be used to add the nodeID to the validator set of subnetID
• remainingBalanceOwner is the P-Chain owner where leftover $AVAX from the validator's Balance will be issued to when this validator it is removed from the validator set.
• disableOwner is the only P-Chain owner allowed to disable the validator using DisableL1ValidatorTx, specified below.

L1ValidatorRegistrationMessage

The P-Chain can produce an L1ValidatorRegistrationMessage for consumers to verify that a validation period has either begun or has been invalidated.

The L1ValidatorRegistrationMessage is specified as an AddressedCall with sourceChainID set to the P-Chain ID, the sourceAddress set to an empty byte array, and a payload of:

Field	Type	Size
codecID	uint16	2 bytes
typeID	uint32	4 bytes
validationID	[32]byte	32 bytes
registered	bool	1 byte
		39 bytes

• codecID is the codec version used to serialize the payload, and is hardcoded to 0x0000
• typeID is the payload type identifier and is 0x00000002 for this message
• validationID identifies the validator for the message
• registered is a boolean representing the status of the validationID. If true, the validationID corresponds to a validator in the current validator set. If false, the validationID does not correspond to a validator in the current validator set, and never will in the future.

L1ValidatorWeightMessage

The P-Chain can consume an L1ValidatorWeightMessage through a SetL1ValidatorWeightTx to update the weight of an existing validator. The P-Chain can also produce an L1ValidatorWeightMessage for consumers to verify that the validator weight update has been effectuated.

The L1ValidatorWeightMessage is specified as an AddressedCall with the following payload. When sent from the P-Chain, the sourceChainID is set to the P-Chain ID, and the sourceAddress is set to an empty byte array.

Field	Type	Size
codecID	uint16	2 bytes
typeID	uint32	4 bytes
validationID	[32]byte	32 bytes
nonce	uint64	8 bytes
weight	uint64	8 bytes
		54 bytes

• codecID is the codec version used to serialize the payload, and is hardcoded to 0x0000
• typeID is the payload type identifier and is 0x00000003 for this message
• validationID identifies the validator for the message
• nonce is a strictly increasing number that denotes the latest validator weight update and provides replay protection for this transaction
• weight is the new weight of the validator

New P-Chain Transaction Types

Both before and after this ACP, to create a Subnet, a CreateSubnetTx must be issued on the P-Chain. This transaction includes an Owner field which defines the key that today can be used to authorize any validator set additions (AddSubnetValidatorTx) or removals (RemoveSubnetValidatorTx).

To be considered a permissionless network, or Avalanche Layer 1:

• This Owner key must no longer have the ability to modify the validator set.
• New transaction types must support modification of the validator set via Warp messages.

The following new transaction types are introduced on the P-Chain to support this functionality:

• ConvertSubnetToL1Tx
• RegisterL1ValidatorTx
• SetL1ValidatorWeightTx
• DisableL1ValidatorTx
• IncreaseL1ValidatorBalanceTx

ConvertSubnetToL1Tx

To convert a Subnet into an L1, a ConvertSubnetToL1Tx must be issued to set the (chainID, address) pair that will manage the L1's validator set. The Owner key defined in CreateSubnetTx must provide a signature to authorize this conversion.

The ConvertSubnetToL1Tx specification is:

type PChainOwner struct {
    // The threshold number of `Addresses` that must provide a signature in order for
    // the `PChainOwner` to be considered valid.
    Threshold uint32 `json:"threshold"`
    // The 20-byte addresses that are allowed to sign to authenticate a `PChainOwner`.
    // Note: It is required for:
    //       - len(Addresses) == 0 if `Threshold` is 0.
    //       - len(Addresses) >= `Threshold`
    //       - The values in Addresses to be sorted in ascending order.
    Addresses []ids.ShortID `json:"addresses"`
}

type L1Validator struct {
    // NodeID of this validator
    NodeID []byte `json:"nodeID"`
    // Weight of this validator used when sampling
    Weight uint64 `json:"weight"`
    // Initial balance for this validator
    Balance uint64 `json:"balance"`
    // [Signer] is the BLS public key and proof-of-possession for this validator.
    // Note: We do not enforce that the BLS key is unique across all validators.
    //       This means that validators can share a key if they so choose.
    //       However, a NodeID + L1 does uniquely map to a BLS key
    Signer signer.ProofOfPossession `json:"signer"`
    // Leftover $AVAX from the [Balance] will be issued to this
    // owner once it is removed from the validator set.
    RemainingBalanceOwner PChainOwner `json:"remainingBalanceOwner"`
    // The only owner allowed to disable this validator on the P-Chain.
    DisableOwner PChainOwner `json:"disableOwner"`
}

type ConvertSubnetToL1Tx struct {
    // Metadata, inputs and outputs
    BaseTx
    // ID of the Subnet to transform
    // Restrictions:
    // - Must not be the Primary Network ID
    Subnet ids.ID `json:"subnetID"`
    // BlockchainID where the validator manager lives
    ChainID ids.ID `json:"chainID"`
    // Address of the validator manager
    Address []byte `json:"address"`
    // Initial continuous-fee-paying validators for the L1
    Validators []L1Validator `json:"validators"`
    // Authorizes this conversion
    SubnetAuth verify.Verifiable `json:"subnetAuthorization"`
}

After this transaction is accepted, CreateChainTx and AddSubnetValidatorTx are disabled on the Subnet. The only action that the Owner key is able to take is removing Subnet validators with RemoveSubnetValidatorTx that had been added using AddSubnetValidatorTx. Unless removed by the Owner key, any Subnet validators added previously with an AddSubnetValidatorTx will continue to validate the Subnet until their End time is reached. Once all Subnet validators added with AddSubnetValidatorTx are no longer in the validator set, the Owner key is powerless. RegisterL1ValidatorTx and SetL1ValidatorWeightTx must be used to manage the L1's validator set.

The validationID for validators added through ConvertSubnetToL1Tx is defined as the SHA256 hash of the 36 bytes resulting from concatenating the 32 byte subnetID with the 4 byte validatorIndex (index in the Validators array within the transaction).

Once this transaction is accepted, the P-Chain must be willing sign a SubnetToL1ConversionMessage with a conversionID corresponding to ConversionData populated with the values from this transaction.

RegisterL1ValidatorTx

After a ConvertSubnetToL1Tx has been accepted, new validators can only be added by using a RegisterL1ValidatorTx. The specification of this transaction is:

type RegisterL1ValidatorTx struct {
    // Metadata, inputs and outputs
    BaseTx
    // Balance <= sum($AVAX inputs) - sum($AVAX outputs) - TxFee.
    Balance uint64 `json:"balance"`
    // [Signer] is a BLS signature proving ownership of the BLS public key specified
    // below in `Message` for this validator.
    // Note: We do not enforce that the BLS key is unique across all validators.
    //       This means that validators can share a key if they so choose.
    //       However, a NodeID + L1 does uniquely map to a BLS key
    Signer [96]byte `json:"signer"`
    // A RegisterL1ValidatorMessage payload
    Message warp.Message `json:"message"`
}

The validationID of validators added via RegisterL1ValidatorTx is defined as the SHA256 hash of the Payload of the AddressedCall in Message.

When a RegisterL1ValidatorTx is accepted on the P-Chain, the validator is added to the L1's validator set. A minNonce field corresponding to the validationID will be stored on addition to the validator set (initially set to 0). This field will be used when validating the SetL1ValidatorWeightTx defined below.

This validationID will be used for replay protection. Used validationIDs will be stored on the P-Chain. If a RegisterL1ValidatorTx's validationID has already been used, the transaction will be considered invalid. To prevent storing an unbounded number of validationIDs, the expiry of the RegisterL1ValidatorMessage is required to be no more than 48 hours in the future of the time the transaction is issued on the P-Chain. Any validationIDs corresponding to an expired timestamp can be flushed from the P-Chain's state.

L1s are responsible for defining the procedure on how to retrieve the above information from prospective validators.

An EVM-compatible L1 may choose to implement this step like so:

• Use the number of tokens the user has staked into a smart contract on the L1 to determine the weight of their validator
• Require the user to submit an on-chain transaction with their validator information
• Generate the Warp message

For a RegisterL1ValidatorTx to be valid, Signer must be a valid proof-of-possession of the blsPublicKey defined in the RegisterL1ValidatorMessage contained in the transaction.

After a RegisterL1ValidatorTx is accepted, the P-Chain must be willing to sign an L1ValidatorRegistrationMessage for the given validationID with registered set to true. This remains the case until the time at which the validator is removed from the validator set using a SetL1ValidatorWeightTx, as described below.

When it is known that a given validationID is not and never will be registered, the P-Chain must be willing to sign an L1ValidatorRegistrationMessage for the validationID with registered set to false. This could be the case if the expiry time of the message has passed prior to the message being delivered in a RegisterL1ValidatorTx, or if the validator was successfully registered and then later removed. This enables the P-Chain to prove to validator managers that a validator has been removed or never added. The P-Chain must refuse to sign any L1ValidatorRegistrationMessage where the validationID does not correspond to an active validator and the expiry is in the future.

SetL1ValidatorWeightTx

SetL1ValidatorWeightTx is used to modify the voting weight of a validator. The specification of this transaction is:

type SetL1ValidatorWeightTx struct {
    // Metadata, inputs and outputs
    BaseTx
    // An L1ValidatorWeightMessage payload
    Message warp.Message `json:"message"`
}

Applications of this transaction could include:

• Increase the voting weight of a validator if a delegation is made on the L1
• Increase the voting weight of a validator if the stake amount is increased (by staking rewards for example)
• Decrease the voting weight of a misbehaving validator
• Remove an inactive validator

The validation criteria for L1ValidatorWeightMessage is:

• nonce >= minNonce. Note that nonce is not required to be incremented by 1 with each successive validator weight update.
• When minNonce == MaxUint64, nonce must be MaxUint64 and weight must be 0. This prevents L1s from being unable to remove nodeID in a subsequent transaction.
• If weight == 0, the validator being removed must not be the last one in the set. If all validators are removed, there are no valid Warp messages that can be produced to register new validators through RegisterL1ValidatorMessage. With no validators, block production will halt and the L1 is unrecoverable. This validation criteria serves as a guardrail against this situation. A future ACP can remove this guardrail as users get more familiar with the new L1 mechanics and tooling matures to fork an L1.

When weight != 0, the weight of the validator is updated to weight and minNonce is updated to nonce + 1.

When weight == 0, the validator is removed from the validator set. All state related to the validator, including the minNonce and validationID, are reaped from the P-Chain state. Tracking these post-removal is not required since validationID can never be re-initialized due to the replay protection provided by expiry in RegisterL1ValidatorTx. Any unspent $AVAX in the validator's Balance will be issued in a single UTXO to the RemainingBalanceOwner for this validator. Recall that RemainingBalanceOwner is specified when the validator is first added to the L1's validator set (in either ConvertSubnetToL1Tx or RegisterL1ValidatorTx).

Note: There is no explicit EndTime for L1 validators added in a ConvertSubnetToL1Tx or RegisterL1ValidatorTx. The only time when L1 validators are removed from the L1's validator set is through this transaction when weight == 0.

DisableL1ValidatorTx

L1 validators can use DisableL1ValidatorTx to mark their validator as inactive. The specification of this transaction is:

type DisableL1ValidatorTx struct {
    // Metadata, inputs and outputs
    BaseTx
    // ID corresponding to the validator
    ValidationID ids.ID `json:"validationID"`
    // Authorizes this validator to be disabled
    DisableAuth verify.Verifiable `json:"disableAuthorization"`
}

The DisableOwner specified for this validator must sign the transaction. Any unspent $AVAX in the validator's Balance will be issued in a single UTXO to the RemainingBalanceOwner for this validator. Recall that both DisableOwner and RemainingBalanceOwner are specified when the validator is first added to the L1's validator set (in either ConvertSubnetToL1Tx or RegisterL1ValidatorTx).

For full removal from an L1's validator set, a SetL1ValidatorWeightTx must be issued with weight 0. To do so, a Warp message is required from the L1's validator manager. However, to support the ability to claim the unspent Balance for a validator without authorization is critical for failed L1s.

Note that this does not modify an L1's total staking weight. This transaction marks the validator as inactive, but does not remove it from the L1's validator set. Inactive validators can re-activate at any time by increasing their balance with an IncreaseL1ValidatorBalanceTx.

L1 creators should be aware that there is no notion of MinStakeDuration that is enforced by the P-Chain. It is expected that L1s who choose to enforce a MinStakeDuration will lock the validator's Stake for the L1's desired MinStakeDuration.

IncreaseL1ValidatorBalanceTx

L1 validators are required to maintain a non-zero balance used to pay the continuous fee on the P-Chain in order to be considered active. The IncreaseL1ValidatorBalanceTx can be used by anybody to add additional $AVAX to the Balance to a validator. The specification of this transaction is:

type IncreaseL1ValidatorBalanceTx struct {
    // Metadata, inputs and outputs
    BaseTx
    // ID corresponding to the validator
    ValidationID ids.ID `json:"validationID"`
    // Balance <= sum($AVAX inputs) - sum($AVAX outputs) - TxFee
    Balance uint64 `json:"balance"`
}

If the validator corresponding to ValidationID is currently inactive (Balance was exhausted or DisableL1ValidatorTx was issued), this transaction will move them back to the active validator set.

Note: The $AVAX added to Balance can be claimed at any time by the validator using DisableL1ValidatorTx.

Bootstrapping L1 Nodes

Bootstrapping a node/validator is the process of securely recreating the latest state of the blockchain locally. At the end of this process, the local state of a node/validator must be in sync with the local state of other virtuous nodes/validators. The node/validator can then verify new incoming transactions and reach consensus with other nodes/validators.

To bootstrap a node/validator, a few critical questions must be answered: How does one discover peers in the network? How does one determine that a discovered peer is honestly participating in the network?

For standalone networks like the Avalanche Primary Network, this is done by connecting to a hardcoded set of trusted bootstrappers to then discover new peers. Ethereum calls their set bootnodes.

Since L1 validators are not required to be Primary Network validators, a list of validator IPs to connect to (the functional bootstrappers of the L1) cannot be provided by simply connecting to the Primary Network validators. However, the Primary Network can enable nodes tracking an L1 to seamlessly connect to the validators by tracking and gossiping L1 validator IPs. L1s will not need to operate and maintain a set of bootstrappers and can rely on the Primary Network for peer discovery.

Sidebar: L1 Sovereignty

After this ACP is activated, the P-Chain will no longer support staking of any assets other than $AVAX for the Primary Network. The P-Chain will not support the distribution of staking rewards for L1s. All staking-related operations for L1 validation must be managed by the L1's validator manager. The P-Chain simply requires a continuous fee per validator. If an L1 would like to manage their validator's balances on the P-Chain, it can cover the cost for all L1 validators by posting the $AVAX balance on the P-Chain. L1s can implement any mechanism they want to pay the continuous fee charged by the P-Chain for its participants.

The L1 has full ownership over its validator set, not the P-Chain. There are no restrictions on what requirements an L1 can have for validators to join. Any stake that is required to join the L1's validator set is not locked on the P-Chain. If a validator is removed from the L1's validator set via a SetL1ValidatorWeightTx with weight 0, the stake will continue to be locked outside of the P-Chain. How each L1 handles stake associated with the validator is entirely left up to the L1 and can be treated independently to what happens on the P-Chain.

The relationship between the P-Chain and L1s provides a dynamic where L1s can use the P-Chain as an impartial judge to modify parameters (in addition to its existing role of helping to validate incoming Avalanche Warp Messages). If a validator is misbehaving, the L1 validators can collectively generate a BLS multisig to reduce the voting weight of a misbehaving validator. This operation is fully secured by the Avalanche Primary Network (225M $AVAX or $8.325B at the time of writing).

Follow-up ACPs could extend the P-Chain <> L1 relationship to include parametrization of the 67% threshold to enable L1s to choose a different threshold based on their security model (e.g. a simple majority of 51%).

Continuous Fee Mechanism

Every additional validator on the P-Chain adds persistent load to the Avalanche Network. When a validator transaction is issued on the P-Chain, it is charged for the computational cost of the transaction itself but is not charged for the cost of an active validator over the time they are validating on the network (which may be indefinitely). This is a common problem in blockchains, spawning many state rent proposals in the broader blockchain space to address it. The following fee mechanism takes advantage of the fact that each L1 validator uses the same amount of computation and charges each L1 validator the dynamic base fee for every discrete unit of time it is active.

To charge each L1 validator, the notion of a Balance is introduced. The Balance of a validator will be continuously charged during the time they are active to cover the cost of storing the associated validator properties (BLS key, weight, nonce) in memory and to track IPs (in addition to other services provided by the Primary Network). This Balance is initialized with the RegisterL1ValidatorTx that added them to the active validator set. Balance can be increased at any time using the IncreaseL1ValidatorBalanceTx. When this Balance reaches 0, the validator will be considered "inactive" and will no longer participate in validating the L1. Inactive validators can be moved back to the active validator set at any time using the same IncreaseL1ValidatorBalanceTx. Once a validator is considered inactive, the P-Chain will remove these properties from memory and only retain them on disk. All messages from that validator will be considered invalid until it is revived using the IncreaseL1ValidatorBalanceTx. L1s can reduce the amount of inactive weight by removing inactive validators with the SetL1ValidatorWeightTx (Weight = 0).

Since each L1 validator is charged the same amount at each point in time, tracking the fees for the entire validator set is straight-forward. The accumulated dynamic base fee for the entire network is tracked in a single uint. This accumulated value should be equal to the fee charged if a validator was active from the time the accumulator was instantiated. The validator set is maintained in a priority queue. A pseudocode implementation of the continuous fee mechanism is provided below.

# Pseudocode
class ValidatorQueue:
    def __init__(self, fee_getter):
        self.acc = 0
        self.queue = PriorityQueue()
        self.fee_getter = fee_getter

    # At each time period, increment the accumulator and
    # pop all validators from the top of the queue that
    # ran out of funds.

    # Note: The amount of work done in a single block
    # should be bounded to prevent a large number of
    # validator operations from happening at the same
    # time.
    def time_elapse(self, t):
        self.acc = self.acc + self.fee_getter(t)
        while True:
            vdr = self.queue.peek()
            if vdr.balance < self.acc:
                self.queue.pop()
                continue
            return

    # Validator was added
    def validator_enter(self, vdr):
        vdr.balance = vdr.balance + self.acc
        self.queue.add(vdr)

    # Validator was removed
    def validator_remove(self, vdrNodeID):
        vdr = find_and_remove(self.queue, vdrNodeID)
        vdr.balance = vdr.balance - self.acc
        vdr.refund() # Refund [vdr.balance] to [RemainingBalanceOwner]
        self.queue.remove()

    # Validator's balance was topped up
    def validator_increase(self, vdrNodeID, balance):
        vdr = find_and_remove(self.queue, vdrNodeID)
        vdr.balance = vdr.balance + balance
        self.queue.add(vdr)

Fee Algorithm

ACP-103 proposes a dynamic fee mechanism for transactions on the P-Chain. This mechanism is repurposed with minor modifications for the active L1 validator continuous fee.

At activation, the number of excess active L1 validators $x$ is set to 0.

The fee rate per second for an active L1 validator is:

$$M \cdot \exp\left(\frac{x}{K}\right)$$

Where:

• $M$ is the minimum price for an active L1 validator

• $\exp\left(x\right)$ is an approximation of $e^x$ following the EIP-4844 specification

  # Approximates factor * e ** (numerator / denominator) using Taylor expansion
  def fake_exponential(factor: int, numerator: int, denominator: int) -> int:
    i = 1
    output = 0
    numerator_accum = factor * denominator
    while numerator_accum > 0:
        output += numerator_accum
        numerator_accum = (numerator_accum * numerator) // (denominator * i)
        i += 1
    return output // denominator

• $K$ is a constant to control the rate of change for the L1 validator price

After every second, $x$ will be updated:

$$x = \max(x + (V - T), 0)$$

Where:

• $V$ is the number of active L1 validators
• $T$ is the target number of active L1 validators

Whenever $x$ increases by $K$, the price per active L1 validator increases by a factor of ~2.7. If the price per active L1 validator gets too expensive, some active L1 validators will exit the active validator set, decreasing $x$, dropping the price. The price per active L1 validator constantly adjusts to make sure that, on average, the P-Chain has no more than $T$ active L1 validators.

Block Processing

Before processing the transactions inside a block, all validators that no longer have a sufficient (non-zero) balance are deactivated.

After processing the transactions inside a block, all validators that do not have a sufficient balance for the next second are deactivated.

Block Timestamp Validity Change

To ensure that validators are charged accurately, blocks are only considered valid if advancing the chain times would not cause a validator to have a negative balance.

This upholds the expectation that the number of L1 validators remains constant between blocks.

The block building protocol is modified to account for this change by first checking if the wall clock time removes any validator due to a lack of funds. If the wall clock time does not remove any L1 validators, the wall clock time is used to build the block. If it does, the time at which the first validator gets removed is used.

Fee Calculation

The total validator fee assessed in $\Delta t$ is:

# Calculate the fee to charge over Δt
def cost_over_time(V:int, T:int, x:int, Δt: int) -> int:
    cost = 0
    for _ in range(Δt):
        x = max(x + V - T, 0)
        cost += fake_exponential(M, x, K)
    return cost

Parameters

The parameters at activation are:

Parameter	Definition	Value
$T$	target number of validators	10_000
$C$	capacity number of validators	20_000
$M$	minimum fee rate	512 nAVAX/s
$K$	constant to control the rate of fee changes	1_246_488_515

An $M$ of 512 nAVAX/s equates to ~1.33 AVAX/month to run an L1 validator, so long as the total number of continuous-fee-paying L1 validators stays at or below $T$.

$K$ was chosen to set the maximum fee doubling rate to ~24 hours. This is in the extreme case that the network has $C$ validators for prolonged periods of time; if the network has $T$+1 validators for example, the fee rate would double every ~27 years.

A future ACP can adjust the parameters to increase $T$, reduce $M$, and/or modify $K$.

User Experience

L1 validators are continuously charged a fee, albeit a small one. This poses a challenge for L1 validators: How do they maintain the balance over time?

Node clients should expose an API to track how much balance is remaining in the validator's account. This will provide a way for L1 validators to track how quickly it is going down and top-up when needed. A nice byproduct of the above design is the balance in the validator's account is claimable. This means users can top-up as much $AVAX as they want and rest-assured knowing they can always retrieve it if there is an excessive amount.

The expectation is that most users will not interact with node clients or track when or how much they need to top-up their validator account. Wallet providers will abstract away most of this process. For users who desire more convenience, L1-as-a-Service providers will abstract away all of this process.

Backwards Compatibility

This new design for Subnets proposes a large rework to all L1-related mechanics. Rollout should be done on a going-forward basis to not cause any service disruption for live Subnets. All current Subnet validators will be able to continue validating both the Primary Network and whatever Subnets they are validating.

Any state execution changes must be coordinated through a mandatory upgrade. Implementors must take care to continue to verify the existing ruleset until the upgrade is activated. After activation, nodes should verify the new ruleset. Implementors must take care to only verify the presence of 2000 $AVAX prior to activation.

Deactivated Transactions

• P-Chain

  • TransformSubnetTx

    After this ACP is activated, Elastic Subnets will be disabled. TransformSubnetTx will not be accepted post-activation. As there are no Mainnet Elastic Subnets, there should be no production impact with this deactivation.

New Transactions

• P-Chain
  • ConvertSubnetToL1Tx
  • RegisterL1ValidatorTx
  • SetL1ValidatorWeightTx
  • DisableL1ValidatorTx
  • IncreaseL1ValidatorBalanceTx

Reference Implementation

ACP-77 was implemented and will be merged into AvalancheGo behind the Etna upgrade flag. The full body of work can be found tagged with the acp77 label here.

Since Etna is not yet activated, all new transactions introduced in ACP-77 will be rejected by AvalancheGo. If any modifications are made to ACP-77 as part of the ACP process, the implementation must be updated prior to activation.

Security Considerations

This ACP introduces Avalanche Layer 1s, a new network type that costs significantly less than Avalanche Subnets. This can lead to a large increase in the number of networks and, by extension, the number of validators. Each additional validator adds consistent RAM usage to the P-Chain. However, this should be appropriately metered by the continuous fee mechanism outlined above.

With the sovereignty L1s have from the P-Chain, L1 staking tokens are not locked on the P-Chain. This poses a security consideration for L1 validators: Malicious chains can choose to remove validators at will and take any funds that the validator has locked on the L1. The P-Chain only provides the guarantee that L1 validators can retrieve the remaining $AVAX Balance for their validator via a DisableL1ValidatorTx. Any assets on the L1 is entirely under the purview of the L1. The onus is on L1 validators to vet the L1's security for any assets transferred onto the L1.

With a long window of expiry (48 hours) for the Warp message in RegisterL1ValidatorTx, spam of validator registration could lead to high memory pressure on the P-Chain. A future ACP can reduce the window of expiry if 48 hours proves to be a problem.

NodeIDs can be added to an L1's validator set involuntarily. However, it is important to note that any stake/rewards are not at risk. For a node operator who was added to a validator set involuntarily, they would only need to generate a new NodeID via key rotation as there is no lock-up of any stake to create a NodeID. This is an explicit tradeoff for easier on-boarding of NodeIDs. This mirrors the Primary Network validators guarantee of no stake/rewards at risk.

The continuous fee mechanism outlined above does not apply to inactive L1 validators since they are not stored in memory. However, inactive L1 validators are persisted on disk which can lead to persistent P-Chain state growth. A future ACP can introduce a mechanism to decrease the rate of P-Chain state growth or provide a state expiry path to reduce the amount of P-Chain state.

Acknowledgements

Special thanks to @StephenButtolph, @aaronbuchwald, and @patrick-ogrady for their feedback on these ideas. Thank you to the broader Ava Labs Platform Engineering Group for their feedback on this ACP prior to publication.

Copyright

Copyright and related rights waived via CC0.