Given that a Subnet can have multiple blockchains, this might not apply to all.

2. Since the validator set management will be driven by a smart contract (which testifies to validator set updates via warp) on any chain in the Avalanche network this can allow for arbitrary logic. Even though the validator set cannot be directly managed from Ethereum and Solana, the smart contract could be deployed on the C-Chain and use cross-chain messaging protocols (CCIP, Axelar, ...) to update the validator set based on ERC-20 staked on Ethereum or any other connected chain.

The idea is Subnet validators can require whatever restriction they'd like to impose. The only thing that the P-Chain requires is a warp message signed by 67% of the voting weight on the Subnet.

How Subnets choose to implement this is entirely up to each Subnet. Subnets may want to coordinate the BLS multi-signature through a smart contract done fully on-chain. Subnets may be okay with doing it fully off-chain by coordinating the BLS multi-signature generation. Subnets may require an Ethereum client in addition to their Subnet client to verify the deposit of ERC-20s on Ethereum. If Subnets want to use a cross-chain messaging protocol like @martineckardt described, that is also possible. The possibilities are truly endless.

Agree on the rebranding front, the word Subnet means a lot to the Avalanche community, but little to newcomers. Onboarding should be simplified whenever possible, and comms matter.

Agree that Landslide is an L1, and we should refer to it in that way.

1.) The AVAX total token supply is not affected by this ACP. It will still be hard called at 720m. Permissionless Subnets are (already today) using their own staking token separate from AVAX that their validators have to stake in addition to the 2k AVAX

2.) Every validator validating the primary network will still have to stake 2k AVAX. The cost of setting up malicious nodes is the same.

This proposal solely suggests that we should allow validators not validating the primary network and only validating a Subnet. These validators do not have to stake 2k AVAX since they do not validate the primary network. These validators cannot attack the Avalanche network since they are just validating the Subnet (similar to how an Ethereum node cannot attack the Avalanche network, since it does not have a say in it)

This proposal would be great for AVAX tokenomics. It will lower the AVAX purchase requirement to operate a subnet, but as they say in business, "we will make it up on volume".

This ACP is needed to unlock the next phase of growth in the Avalanche ecosystem.

I wrote a short thread discussing the 2000 $AVAX removal: https://twitter.com/dhrubabasu_/status/1784294145009524972

The idea is to have fault isolation between Subnet validators from Primary Network validators. By separating them, it's guaranteed that a fault on a Subnet does not cause issues on the Primary Network and vice versa.

Validators are not precluded from being both a Primary Network validator and a Subnet validator on the same machine. However, they’ll be charged as if they are different validators. If you are validating 6 subnets, you’ll be charged as if you are 6 different validators.

Where is the incentive for primary network validators to validate subnets on different machine than that which they use to validate the primary network? If anything there is disincentive because it's just more server fees for them to pay. If a subnet got so large that it had more validators than the primary network, and a majority of the primary network validators were participating in validating this subnet while using same machine as they use to validate the primary network, then any fault on the subnet that causes validator nodes to go down will effect the primary network too.

It might need a minimum set of features such as changeOwner to prevent a subnet being permanently locked to a specific version of a contract?

This is a good point, we will likely need a SetSubnetValidatorManagerTx that specifies the BlockchainID and Address that controls the Subnet's validator set. I will update the ACP.

Would there be any need for a distinction between permissioned and permissionless subnets in this case? It could just be a matter for the controlling contract.

Very astute observation. I think it should be left entirely up to the Subnet whether they do PoA or PoS or even a hybrid of both. We likely wouldn't remove the existing subnet creation flow in the upgrade that ACP-77 is activated but may consider it in the future. (Commented here as well: #78 (reply in thread))

Where does the continuous staking fee go? Is it burned or redistributed or a mix of both. I would really like to see it at least partially redistributed in a manner similar to how delegations accrue rather than determined at the point of staking.

Like all other fees on Avalanche, the ACP advocates for burning it. A larger conversation should probably be had around tokenomics, likely in a separate ACP. This ACP changes a lot of dynamics as-is.

Regarding burning fees versus distributing them as rewards:
Who benefits from burned fees? All token holders. Who benefits from rewards? The holders who stake their tokens. Do we want to motivate people to just hold tokens? Or do we want to motivate them for staking the tokens? I definitely want to motivate them to stake the tokens, because it makes the participation of holders more active plus it improves the economics for all holders by reducing liquid supply. Can anybody explain what is the logic for choosing burning fees instead of using the fees for paying rewards?
Also if there is fixed max supply of AVAX and fees are burned it means that at some theoretical point in future there will be 0 AVAX, so there will have to be some changes to the token issuance/fee burning. This creates uncertainty for the investors. I prefer solid future-proof economic design that does not have built-in the necessity for inflationary change at some point in future. Ideally fees should be split between stakers and ecosystem adoption/development.

I mentioned this in an earlier comment:

Like all other fees on Avalanche, the ACP advocates for burning it. A larger conversation should probably be had around tokenomics, likely in a separate ACP. This ACP changes a lot of dynamics as-is.

Personally, I think the tokenomics need to be modified to account for the fixed supply and the rate of burn at some point. I don't think this is the ACP to do it though. Any tokenomics change should consider all burned fees rather than this specific fee IMO.

+1 for "Avalanche Realms"

also have similar questions about the validator balances.
from my understanding the IncreaseBalanceTx would have to be fired from the subnet to increase the funds of a validator. how would AVAX flow from the subnet to the P-Chain, does C-Chain need to get involved in the process (bridge AVAX from Sub to C, then to P)?

i think having a "clear migration path" from permissioned subnets would also have great value!

ACP-77 does not introduce the Warp Derived Address that #73 discusses.

The initial Balance in RegisterSubnetValidatorTx is taken out of the inputs of that transaction. Anybody can issue the RegisterSubnetValidatorTx, there is no requirement that it is issued to the P-Chain by the Subnet, by the Validator itself, by a third-party service, etc etc. Whoever is paying for the initial Balance should issue the RegisterSubnetValidatorTx.

The migration path does need to be clearer, I'll work on updating the ACP with a more fleshed out description of the path. It'll look like an additional transaction type to move from PoA to a (source_chain_id, sourceAddress) pair that will be stored on the P-Chain to validate the AddressedCall in RegisterSubnetValidatorTx and EvictSubnetValidatorTx.

To be clear, this would be a Warp Derived Address. We don't need to use the same term, but if we are using (sourceChainID, sourceAddress) as originally laid out in the draft for ACP-73, then it would be using the idea of a Warp Derived Address, which I think is exactly what we want.

In ACP-73, there was a notion of transferring funds to the "Warp Derived Address".

ACP-77 does not introduce the Warp Derived Address that #73 discusses.

The main delineation I was making with this comment is that the (sourceChainID, sourceAddress) pair is only used for authorization in ACP-77 and does not control any funds itself (similar to how the PoA key does not control any funds itself). No "Warp Derived Address" needs to be funded in order to issue a RegisterSubnetValidatorTx, SetSubnetValidatorManagerTx, or SetSubnetValidatorWeightTx on the P-Chain. The issuer of those transactions are expected to cover the fee using their own P-Chain UTXOs.

The target utilization refers to the capacity of the P-Chain. The P-Chain is the registry for Subnets, its validators and their BLS keys. Like any blockchain it has a limited capacity to record the data and process updates to it on-chain.

Like many other blockchains it uses a token to balance the demand and supply. If it is used more than intended the price of issuing P-Chain transaction goes up, if less than it goes down.

If you are familiar with the EVM you may know the concept as gas target. This is fees go up in times of high activity (NFT drops etc.)

This target is solely based on the P-Chain utilization, not on the usage of the Subnet. In fact the P-Chain has no data on how much a Subnet is used. So Subnets with a lot of transactions do not get priced differently than low-activity Subnets.

Would this ACP create a congestion issue when subnet only validators are mismanaging their networks? Or theoretically, couldn't a bad subnet actor/s, create multiple subnets and operate them above target utilization purposefully...thus pushing up the dynamic fee for all users and creating congestion on the P-chain..could this limit or threaten the security of the P-Chain itself?

Basing this off how the ACP reads here..." standard charge that all subnet validators will pay will be calculated by the network based on network activity, commonly referred to as a "base fee". This base fee will move up when the total number of subnet validators is above target utilization and move down when the total number of subnet validators is below target utilization."

If Subnets want to retain the 2000 $AVAX requirement, they can choose to do so. The core premise of ACP-77 is to push as much decision-making to Subnets as possible to empower Subnet creators. By mandating that all Subnet validators stake 2000 $AVAX in addition to the Subnet staking token, Subnets were less desirable than they could be.

After ACP-77 is activated, Subnets can choose whatever security model they like.

Let's imagine a potential world where ...

• ACP77 is implemented
• 10's of thousands of subnets boot up over time
• Many subnets gain massive traction and have major exchange listings and native USDC and USDT.
• Boot strapping subnets get their security from re-staking other large tokens.
• C-chain becomes obsolete because everyone is just spinning up their own application specific deluxe custom Subnet. EVM has fallen out of favor anyway.
  -The core use case for AVAX has become paying fees through the Continuous Fee Mechanism(CFM). There are still secondary uses of the token's value; things like loans, some re-staking, market-making, etc. Those are secondary to it's core function.

Question about this scenario:

1. What security trade-offs are there if CFM is the main use case for AVAX?
2. I believe Elastic Subnets would have made it easy to validate multiple networks. Is there another way to bring this function back?
3. What is the max throughput of the P-chain in metrics of number of supported chains/activity? I'm assuming the main activities on P-chain are updating validator sets, balance management, and reads for AWM.

This is an interesting scenario you’ve proposed. :

• Security trade-offs if CFM is the main use case for AVAX: If the Continuous Fee Mechanism (CFM) becomes the main use case for AVAX, one potential security trade-off could be a decrease in the incentive for validators to secure the network. Validators are rewarded with AVAX for their work in securing the network, and if the primary use of AVAX shifts to paying fees, the rewards for validators might decrease, potentially leading to less security. However, this would depend on the specifics of how the CFM is implemented and how fees are distributed.
• Elastic Subnets and validating multiple networks: Elastic Subnets would indeed make it easier to validate multiple networks. If Elastic Subnets are not available, one alternative could be to manually configure validators to participate in multiple subnets. However, this would likely be more complex and less flexible than using Elastic Subnets.
• Max throughput of the P-chain: The maximum throughput of the P-chain would depend on a number of factors, including the hardware and network conditions of the validators. As a scalable blockchain, Avalanche can achieve high throughput of 4,500 transactions per second while preserving adequate decentralization. However, the specific throughput of the P-chain in terms of number of supported chains or activity could vary.

In addition, if ACP77 is implemented and leads to an increase in the use of subnets, validators on the main network could indeed see a decrease in their relative utility. This could potentially lead to a reduction in the number of small validation nodes (for example, those staking 2000 AVAX), as the maintenance costs of these nodes may no longer be justified by the rewards they receive.

At the same time, this could incentivize validators to increase the size of their stake (for example, to more than 4000 AVAX) in order to remain competitive and continue to receive sufficient rewards to cover their maintenance costs.

However, it’s important to note that this will depend on many factors, including how ACP77 is implemented, how fees are structured in the Avalanche network, and the market dynamics of validators and subnets.

Ultimately, it will simply be an economic calculation for the small nodes on the Avalanche main network.

Security trade-offs if CFM is the main use case for AVAX

The rewards for validators are progressively decreasing as the total amount of AVAX approaches 720M AVAX as defined in the minting curve. This isn't a problem unique to Avalanche. Bitcoin, with a fixed supply of 21M BTC, has also had concerns raised from its community around its security budget because the miner reward rate halves every four years.

I firmly believe this is not the ACP to solve this problem as ACP-77 does not modify the reward rate for any Avalanche Primary Network validators. Only 0.24% of the total AVAX stake is validating Subnets (source: https://snowpeer.io).

Elastic Subnets and validating multiple networks

The idea is to have fault isolation between validators of different networks. By separating them, it's guaranteed that a fault on a Subnet does not cause issues on any other Subnet or the Primary Network from overlapping validator sets.

Note that validators are not precluded from being both a Primary Network validator and a Subnet validator on the same machine. However, they’ll be charged as if they are different validators. If you are validating 6 subnets, you’ll be charged as if you are 6 different validators with regards to the P-Chain continuous fee.

Max throughput of the P-chain

Before ACP-77 can be considered "Implementable," an analysis must be done to explicitly set the maximum number of Subnet validators and the target number of Subnet validators. Part of this analysis will include the limitations of the P-Chain state for managing Subnet validator sets among the other responsibilities it has.

"Security trade-offs if CFM is the main use case for AVAX: If the Continuous Fee Mechanism (CFM) becomes the main use case for AVAX, one potential security trade-off could be a decrease in the incentive for validators to secure the network."

I don't believe this is the case, as the validation rewards currently stem from emissions, which shouldn't be affected in regards to ACP-77. Hence C-Chain validation should scheme should continue to run its natural course, unaffected.

Please correct me if I have stated anything inaccurate, would actually appreciate having the statement I made confirmed.

@jfsaine That is correct. Primary Network Validation is the only thing that results in new AVAX emissions.

1. The IncreaseBalanceTx can be issued by anybody who is willing to pay the fee. It is a P-Chain transaction and does not originate from any Subnet. You will need AVAX on the P-Chain to top-up a validator.

2. This is entirely left up to Subnets. The only registration done on the P-Chain is the Subnet validator itself along with the weight of the validator. I think ACP-77 has to be modified to support updating an existing validator's weight if we want to make Subnet delegation easy. Currently to update a validator's weight you have to remove it and then re-add it which isn't a great flow.

3. I'm not sure how this would work on the Subnet-level tbqh. I think bad behavior detection is still an open question. ACP-77 does not modify this dynamic as Elastic Subnets had the same DX w.r.t. detecting inactivity or malicious behavior.

For ZAWM as its own communication protocol to complement or build on Warp, this seems even more compelling.

I wrote up my thoughts on making the P-Chain more general, so that it can index the data required for arbitrary communication protocols here: https://gist.github.com/aaronbuchwald/cf71cbd54aecdfca3f462c7f1b7b6710.

Storing the commitments required by ZAWM on the P-Chain could be a great use case for this.

The remaining question to me is really, would it be better to put something like this on the P-Chain or the Primary Network in general, rather than on its own Subnet.

In my opinion, there's a delicate balancing act for the Primary Network. On one hand, it should provide a minimal base layer to build on top of. A principle goal for the P-Chain should be to reduce the risk of any issues impacting L1s built on top of Avalanche in any way.

At the same time, the Primary Network is maximally decentralized and is uniquely positioned to provide a certain set of common services to all L1s building on Avalanche. Cross-chain communication via Warp is one example. The C-Chain provides a hub for assets similar to the role Noble plays in Cosmos. A more generic P-Chain to facilitate the development of custom cross-chain protocols could fit here as well.

I think there's a small set of additional services that the Primary Network validator set could provide as well. Identity and authorization are good example imo.

Thank you for reviewing ZAWM in detail. I completely agree with the concern about implementing novel (i.e., not yet battle-tested) cryptographic protocols directly into the Primary Network, especially without providing any alternatives first.

That being said, one caveat is that the subnet would still be exposed to the possibility of refreshing and then updating to an earlier validator set, since someone could post a proof that only brings you part way to the most up to date version.

To construct the Rotate proof, the new validator set information must be signed by the current validators, who first check whether the information is well-formed and up-to-date. If I understand correctly, in the scenario you mentioned, validators should not sign the old data since they are all aware of each other. However, there could be a malicious relayer who has stored a previous proof and signature to post later to the P-chain. In this case, if the rotation is well-incentivized by the subnet (as it should be), anyone noticing a discrepancy between the validator sets could immediately update the P-chain with the new validator set. I'm not sure if I missed anything though, so I would appreciate it if you could elaborate more on this.

Others have said that due to its immaturity and the possibility of a prover bug, ZK L2s should only be decentralized after multi-provers are implemented, so that a bug in a single prover implementation does not result in a critical failure.

This is also quite reasonable, but in the case of ZAWM, its circuits do not require altering the default proving system with complicated operations (e.g., GKR to speed up some computations). Thus, it is much less likely to encounter low-level security vulnerabilities (like soundness bugs) compared to the prover implementations of L2s, which require many novel techniques to speed up their extremely heavy circuits. We just used the default flow of the gnark on ZAWM, which compiles circuits to R1CS. This means anyone can generate proofs with other provers such as rapidsnark, arkworks and others. It requires a bit of manual work to convert gnark's R1CS to circom's R1CS, but the conversion from circom to arkworks is trivial). Therefore, this should not be a direct concern, as proof verification in ZAWM's case is essentially a few pairing computations on BN254, which already has a precompile in the C-Chain. Still, of course, no one can guarantee anything here.

The remaining question to me is really, would it be better to put something like this on the P-Chain or the Primary Network in general, rather than on its own Subnet.

I am still trying to figure out a specific answer to this. Considering the ease of launching a subnet after the ongoing upgrades, I think the subnet thesis already provides sufficient flexibility for teams in the Avalanche community to build subnets for such problems in more customized ways. One skilled team working on similar subnets is the Ash team, for example. As a result, it seems that one needs to consider potential applications that will require data on the P-Chain to benefit from the security provided by the Primary Network. After all, new protocols will likely choose the option that offers higher flexibility with lower costs. If the security of the PN is not necessary for those protocols, they will probably choose the subnet instead of the P-Chain. So, the General P-Chain could potentially provide increased security and a more straightforward flow for accessing commitments in the context of ZAWM, but I am obviously biased, and it might be more insightful to gather feedback and perspectives from other teams on this.

To construct the Rotate proof, the new validator set information must be signed by the current validators, who first check whether the information is well-formed and up-to-date. If I understand correctly, in the scenario you mentioned, validators should not sign the old data since they are all aware of each other. However, there could be a malicious relayer who has stored a previous proof and signature to post later to the P-chain. In this case, if the rotation is well-incentivized by the subnet (as it should be), anyone noticing a discrepancy between the validator sets could immediately update the P-chain with the new validator set. I'm not sure if I missed anything though, so I would appreciate it if you could elaborate more on this.

Yes, you're right that anyone could notice and send an update after the fact. However, at that point, it's possible for an attacker to fast forward to a specific point and immediately send a message that is considered valid based off of an old validator set. If they control that historical validator set, then they can construct a new warp message at that point to go in a different direction to what had already happened. So, once you open up a brief window of attack, there's the possibility of escalation to a takeover depending on the security model you want to take.

This is also quite reasonable, but in the case of ZAWM, its circuits do not require altering the default proving system with complicated operations (e.g., GKR to speed up some computations). Thus, it is much less likely to encounter low-level security vulnerabilities (like soundness bugs) compared to the prover implementations of L2s, which require many novel techniques to speed up their extremely heavy circuits. We just used the default flow of the gnark on ZAWM, which compiles circuits to R1CS. This means anyone can generate proofs with other provers such as rapidsnark, arkworks and others. It requires a bit of manual work to convert gnark's R1CS to circom's R1CS, but the conversion from circom to arkworks is trivial). Therefore, this should not be a direct concern, as proof verification in ZAWM's case is essentially a few pairing computations on BN254, which already has a precompile in the C-Chain. Still, of course, no one can guarantee anything here.

This perspective makes sense to me

I am still trying to figure out a specific answer to this. Considering the ease of launching a subnet after the ongoing upgrades, I think the subnet thesis already provides sufficient flexibility for teams in the Avalanche community to build subnets for such problems in more customized ways. One skilled team working on similar subnets is the Ash team, for example. As a result, it seems that one needs to consider potential applications that will require data on the P-Chain to benefit from the security provided by the Primary Network. After all, new protocols will likely choose the option that offers higher flexibility with lower costs. If the security of the PN is not necessary for those protocols, they will probably choose the subnet instead of the P-Chain. So, the General P-Chain could potentially provide increased security and a more straightforward flow for accessing commitments in the context of ZAWM, but I am obviously biased, and it might be more insightful to gather feedback and perspectives from other teams on this.

Yup, I agree. I think it's best to wait until there's a clear problem to be solved. For now, Warp is still early in adoption and there's not a clear performance bottleneck yet. It makes sense to re-evaluate this down the line as it becomes clear where improvements are needed and see if ZAWM + Generic P-Chain could be a good solution.

The P-Chain is secured solely by the total amount of AVAX staked from Primary Network Validators. 0.24% of the total AVAX stake is additionally validating Subnets (source: https://snowpeer.io). If all the Subnet validators stop staking their AVAX if/when ACP-77 activates, the Primary Network will be unaffected from a security perspective.

The 2000 AVAX minimum stake that Subnet validators had to put up never realistically provided any additional security to Subnets. If a single Subnet validator put up the 2000 AVAX minimum stake and had 99% of the Subnet's voting weight, the Subnet will treat them as if they are the entire validator set. It does not matter whether other Subnet validators has more AVAX staked. Subnets were solely responsible before for their security and they are still responsible for their security if/when ACP-77 activates.

Thanks. I may not have been clear. My question is, under ACP-77, what security does the 2000 AVAX staking for the X/P/C-chain give to the P-chain specifically? I'll offer that staking secures the governance process for the P-chain. I don't think that the P-chain derives nor needs any other security from staking, is that correct?

Staking, in general, does not only secure the governance process of a chain. If an attacker gains enough stake to control a proof-of-stake system, they can cause tremendous harm like minting themselves an infinite amount of AVAX. You can read more about proof-of-stake here: https://consensys.io/blog/what-is-proof-of-stake.

A notable difference between Avalanche's use of proof-of-stake versus other chains that use proof-of-stake is that the initial AVAX stake is never at risk of slashing. This isn't really the forum to discuss proof-of-stake though. If you have any other questions/concerns specifically related to ACP-77 we can discuss it here.

AVAX is not minted on the P-chain. While the X/C-chain are also secured by the same stake currently, they have different security needs that you have alluded to.

My question is specifically about staking's security benefits for the P-chain. I'm asking for this clarification as the basis of another question about ACP-77. I think my understanding is correct, that staking's only security benefit for the P-chain is the governance process for the P-chain.

AVAX is only minted on the P-Chain in the form of staking rewards.

I think you may be misunderstanding what security proof-of-stake provides to blockchains. I recommend reading the blog post I linked above and asking further questions in our Discord. As ACP-77 does not modify any staking requirements for the Primary Network, I don't think this is related to this discussion thread.

The continuous fee mechanism is needed to prevent a spam attack on the p-chain. Yes, an attacker could temporarily produce a high load on the p-chain that would impact small subnets, but doing so would be very expensive, and the amount of AVAX burned by the attacker would benefit the entire ecosystem, like we saw with the inscriptions craze.

There's also no incentive to do this, other than a malicious actor intentionally trying to DoS the chain. The p-chain is only used for bookkeeping about the subnets and their validator sets, which should not produce much load. All the other transaction load, including warp messaging, is isolated to within the subnets, and would not be impacted by a slowdown on the p-chain.

The Subnet with a huge validator set would be charged that fee per validator.

If it has a validator set of size 100,000 and most validator sets are 100 or 1,000 validators it would be 100-1,000x more expensive for the large Subnet than the others.

At the end of the day, the options are using a market mechanism, incorrect pricing of resources, or achieving infinite scale.

A market mechanism is the most robust apporach imo and future improvements can continue to increase the target rate.

Another thought here - at least with the per subnet validator approach - is to require a minimum balance per subnet validator. This makes it extremely easy to create a bound of how much it would cost to hit the target rate.

For example, if every validator requires a minimum balance of 1 AVAX, then it costs at least 100k AVAX to hit a target of 100k validators (note that this is easily parameterizable).

Another thought here - at least with the per subnet validator approach - is to require a minimum balance per subnet validator. This makes it extremely easy to create a bound of how much it would cost to hit the target rate.

I think enforcing on a time basis would be better than a raw AVAX amount. This would make the minimum go up as the rate goes up. 24 hours (1 day) seems logical to me, I don't think it's that useful to be a validator for less than that in the normal case. Validators can still exit at any time and claim the remaining balance so this has the nice property of making intermittent validator set expansion attacks more expensive faster while not requiring a significant upfront cost for normal users.

If the current rate is 0.1 AVAX/hr, new subnet validators can only be instantiated with 2.4 AVAX. If the rate goes up to 0.2 AVAX/hr, new subnet validators can only be instantiated with 4.8 AVAX.

Why get rid of subnet validator staking requirements?

Because $60,000 USD (at current prices) to launch an app-chain is an outrageous amount of money that many people in the developing world will not see in their entire lives, let alone be able to set aside for launching a personal project.

where is the new usage going to come from to justify it’s potential in terms of token valuation?

From the massive number of web3 applications that will need AVAX to register and manage their chains.

BTW, this proposal does not change any of the existing utility of AVAX. You can still use it for all the things you can use it for today, including validating the primary network with 2000 AVAX, which more people would be interested in doing as the network grows. This ACP just adds a new utility -- launching and managing subnet-only validators.

Because $60,000 USD (at current prices) to launch an app-chain is an outrageous amount of money

The existence of staking requirements are not an all or nothing choice. If 2000 is high, one option is to reduce it to 500. Another option is Pay-as-you-go(PAYG) validating. If the subnet can't afford validator stake, they could pay a fee to another fully staked validator who is willing to provide the service. Another option is a rent to own model with PAYG where once you've paid enough fees you will be given enough AVAX to run your own validator. It would be fine with me to stop validating the C-chain as outlined, but still require stake for P-chain validators.

From the massive number of web3 applications that will need AVAX to register and manage their chains.

It is not at all clear how much AVAX subnets spend on the P-chain. I've seen no transaction cost estimates. The dev's themselves said that in the beginning it was likely to be almost nothing. Fees, even fees burnt, are way less impactful on demand than sinking AVAX in a Validator.

I sound like a salty bag holder, but I'm totally in for the tech it be successful whatever the price. I just might need decide on a different valuation technique that more closely resembles a new realty where the AVAX has a low market cap but is used for an amazing low cost utility connecting a sea of blockchains. Why? because there is nothing to slow the velocity of this money down, like staking many chains. PAYG fees for P-chain are simply not high enough to warrant AVAX's multi-billion dollar valuation. I personally think the founders and VC's of this chain expect more from their efforts on building this token and ecosystem. I'd love to see a monetary premium develop for AVAX.

BTW, this proposal does not change any of the existing utility of AVAX.

That is just not the case. Subnets will no longer have to stake AVAX to be part of the network. So, not just current subnets, but all future one will also not have to stake AVAX. Only C-chain will remain unchanged, but that is not wholly the case either. I ran a validator for a while at a loss with sole goal of eventually being able to validate subnets via elastic subnets.

This ACP just adds a new utility -- launching and managing subnet-only validators.

This not a new "utility". It's a different format of something that is already required of subnets, except that no stake is needed.

1. I agree @Adventuremonkey's comment. It is not clear to how the price of AVAX would grow with the network when subnet proliferate. I am in for the tech and that's why I was attracted to avalanche. But I suspect this proposal would kill AVAX price completely.

2. I would question Avalab (dev and its CEO Emin Sir) how demand of AVAX would be affected by this proposal. I granted that they are not allowed to speculate the price of AVAX, but it is wholly legitimate to talk about demand. Given the supply cap of AVAX is fixed, that's the only variable we need to figure out.

3. I am running a validator too. Shouldn't this kind of change be a vote by all validator runners?

It's inappropriate to talk about price in a tech-focused forum. Please discuss it elsewhere.

I ran a validator for a while at a loss with sole goal of eventually being able to validate subnets via elastic subnets.

As outlined in the ACP, there is no demand to create Elastic Subnets considering the 2000 AVAX economic constraints that exist today. I believe this change needs to be made to enable Subnet adoption.

Being a Primary Network Validator simply gave you the ability, not the right, to be a Subnet Validator. If an Elastic Subnet did exist on the Avalanche Primary Network, you would have needed to acquire enough of the Elastic Subnet's staking token to become a validator. This does not change under ACP-77.

After ACP-77, anybody has the ability to be a Subnet Validator as long as they pay the P-Chain continuous fee. As mentioned in other responses, simulations will be released to show what the fee will look like after the work in #69 progresses.

I am running a validator too. Shouldn't this kind of change be a vote by all validator runners?

From the ACP README (https://github.com/avalanche-foundation/ACPs/blob/main/README.md)

ACPs are an open framework for proposing improvements and gathering consensus around changes to the Avalanche Network. ACPs can be proposed by anyone and will be merged into this repository as long as they are well-formatted and coherent. Once an overwhelming majority of the Avalanche Network/Community have signaled their support for an ACP, it may be scheduled for activation on the Avalanche Network by Avalanche Network Clients (ANCs). It is ultimately up to members of the Avalanche Network/Community to adopt ACPs they support by running a compatible ANC, such as AvalancheGo.

is there a timeline or eta for this acp to go live on mainnet?

There is currently no ETA. Fuji Activation will come before Mainnet Activation though so it will be a few months at minimum.

how many avax have been staked by subnet validators currently, if it is not a signficant number now then our worries regarding the negative incentive effect might be baseless

https://snowpeer.io/ has excellent stats for this. 547k AVAX is staked in Subnet validators (0.12% of total AVAX supply and 0.22% of the total AVAX stake). A significant amount of this is provided by Subnet-as-a-Service providers like GoGoPool and AvaCloud who will likely continue to stake the AVAX to accrue the Primary Network Validator staking rewards. For comparison, the 24h trading volume of AVAX is 13M AVAX.

Can the 500 min avax part be implemented first ?

There is no 500 min AVAX part in ACP-77.

it seems very little to none negative effect on price action looking at the number of avax used by subnet validators. I hope everything goes smoothly with the acp77.

This isn't really possible. The deposit will be continuously drained to pay for the continuous fee mechanism which means the amount you have deposited is not stable for any period of time.

I understand why this is not possible in the current proposal, but the payment of the fees is not very convenient from a user perspective. It will also cause a lot of unnecessary traffic on the P-Chain (imagine 100k validators topping up their balance every month) and make the tax return more difficult. For these reasons, I'm also in favor of subnets paying the fees collectively (as discussed above).

Setting the multi-dimensional fee for the subnets is not easy. I'm looking forward to the simulations. I think the number of validators of each subnet should also be taken into account to support decentralization (the more validators per subnet, the lower the fee per validator).

I'm also in favor of subnets paying the fees collectively (as discussed above).

The subnet-fee paying comment has been discussed in the other thread (#78 (reply in thread)). There's still a few blocking reasons why it isn't possible so ACP-77 will continue forward with the individual validator approach at this time.

It will also cause a lot of unnecessary traffic on the P-Chain (imagine 100k validators topping up their balance every month) and make the tax return more difficult.

I wouldn't consider the traffic "unnecessary". Validators need to top up their balance as frequently as they want. If I fill it up with 10k AVAX, I wouldn't have to issue another top up transaction for a very long time. If I want to fill up enough for a month, I need to re-fill every month. The P-Chain's dynamic fee mechanism will account for this traffic. Having the Subnet pay the fee collectively would run into the same issue albeit at a higher level of adoption (100k Subnets instead of 100k Validators).

I think the number of validators of each subnet should also be taken into account to support decentralization (the more validators per subnet, the lower the fee per validator).

Why should this be the case? The P-Chain load per validator is relatively fixed

Why should this be the case? The P-Chain load per validator is relatively fixed

I'm afraid there will be a tendency towards centralization if fees are directly proportional to the P-Chain load. There could be large centralized subnets with millions of users paying very low fees. However, fees are a difficult topic and will probably need to be adjusted from time to time anyway. So let's see how this develops.

By the way - thanks for taking the time to reply to all these posts and sometimes crazy ideas!

I don't think it makes a lot of sense for the P-Chain to incentivize decentralization since that would effectively be paying people to increase the amount of load on the network.

I do understand the concern of centralization but I think that's something that needs to be demanded by the users of the Subnet rather than the P-Chain imposing it on the Subnet.

By the way - thanks for taking the time to reply to all these posts and sometimes crazy ideas!

❤️

You may want to post this suggestion in https://github.com/avalanche-foundation/ACPs/discussions/categories/brainstorming rather than as a comment on this ACP. I don't think ACP-77 could be reasonably updated to something like this since it is a pretty far departure from how it is proposed.

I created the discussion as you suggested. It's called, "Disentangle X-P-C-chains. Inspired by ACP-77 #88" and is located #88

It's hard to develop a perfect model for the Continuous Fee (CF) from the start.

CF will be mainly driven by the P-Chain resources used (hence, it should be dynamic), by open market fees (i.e., what's the cost of launching and maintaining a blockchain), and by the overall profitability of subnets (i.e., subnet validators may want to sell subnet rewards to pay for CF in AVAX but if only a few subnets are profitable, high CFs might still hinder the adoption of subnets.)

I hope someone from the community rolls up their sleeves and works on tokenomics to give us more insight into the post-ACP-77 era.

Meanwhile, I have advised the Foundation to hire a tokenomics firm to better understand the impact of ACP-77 on network stability, security, and subnet adoption.

Thanks for the detailed description of the attack! @aaronbuchwald also mentioned a scenario in the same vein as this attack in an earlier comment:

In the current design of ACP-77, when the P-Chain state size hits the target rate, the fee rate rises until evictions bring the state size back below the target. This could trigger a pathological case where multiple validators are evicted from a single subnet in quick succession. For example, if a Subnet has 10 validators where one with a minority stake is malicious, the P-Chain could evict the 9 honest nodes first leaving a single malicious validator that has then taken over the Subnet.

We definitely need to evaluate the cost of this attack. Simulations from the work being done for ACP-83 should help quantify the cost of this attack and inform what approach ACP-77 should take to address this attack vector.

This issue is critical and should not be postponed for future review. In my view, there is nothing more problematic than introducing new trust assumptions and security models along the way. As @patrick-ogrady mentioned, one should definitely introduce other safeguards, like an extra layer of check, to prevent this kind of malicious spamming. Additionally, a deterministic and cryptographically sound mechanism might offer better reassurance to newcomers.

As a quick idea, one (if) possible approach could be to require a some kind of "proof of acceptance" for registering a validator to the subnet on the P-chain. Assuming post ACP-77, subnets will govern their validators as sovereign chains, a new validator with enough subnet tokens could "partially" join that subnet. Subsequently, existing validators could sign the new validator's [BLS public key] concatenated with +[str(accepted)]+[date] and broadcast their signatures to the new validator back (or a relayer could collect them and send it directly to the P-chain as an AWM tx) which aggregates those signatures and send it to the P-chain as an AWM payload. If P-chain could verify the signature using the public keys of the existing validators, (and check if its signed by the majorith >2/3 stake etc.) it registers the BLS public key (which is the part of the signed payload) of the new validator to that subnet. This mechanism could allow Mainnet’s RPC nodes to preemptively reject invalid signatures, preventing spam.

Obviously there may be nuances I’m overlooking, but this or similar kind of a method would be great guarantee for such sensitive attack vectors.

@altl1 The registration process for a Subnet Validator in ACP-77 already mirrors what you have written. See the "New Registration Flow" section here: https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/77-reinventing-subnets#new-registration-flow.

@dhrubabasu Apologies for not catching this earlier. Could you explain why that approach isn't sufficient to prevent such spam attacks?

Also @RnSpartners said :

theoretically, couldn't a bad subnet actor/s, create multiple subnets and operate them above target utilization purposefully...thus pushing up the dynamic fee for all users and creating congestion on the P-chain..

To prevent that, is it possible to define a seperate "entrance fee" for registering new validators to a subnet? Entrance fee can be minimal (0.5/1 avax) as the base, and could increase based on the "no. of registrations @ that subnet / sec" which only affects "new validators", rather than already existing ones in that subnet?

If someone creates his own subnet and spams "legit" signatures of acceptance to the P-Chain, even though the fees of other subnets starts increasing, the entrance fees for the attacker's new validators will be increasing exponentially (this increase could be made more aggresive compared to increase in the continuous fee, maybe be even hyperbolic). This steeper increase in entrance fees could financially overburden the attacker, while contributing to the burn of avax token.

The core problem is that a bad actor can impact safety of the Subnet without using the staked token. The proof-of-stake security model isn't upheld with the continuous fee mechanism since a Subnet Validator being evicted would impact consensus weights.

I believe this can be solved by adding an "inactive" state for Subnet Validators. I've taken a stab at outlining that here: #94

The current implementation uses this optimization because every Subnet synced the C-Chain when it was developed. To make this change, VMs will need to provide support for choosing between the options @StephenButtolph stated above.

I wouldn't call it a problem just an additional tradeoff that Subnets/VMs can decide on if it fits their needs better. If they want to continue syncing the C-Chain to continue using this optimization they can.

While Subnets may have options on how they recv messages from the C-Chain, how will coreth be modified to handle ACP77? Messages sent to the C-Chain will now need to be signed by 67% of the total network stake? So it seems that every Subnet that wants to send msgs to C will need to get them signed by all 1600+ validators? Are PN validators expected to sign an unbounded number of messages from all these subnets (at no cost)? I think there is something I am missing in my understanding.

Ah I see where the misunderstanding is. The C-Chain considers a message from a Subnet valid if 67% of the stake of that subnet has signed the message. There is no need for the C-Chain (Primary Network) validators to sign a message that is sent from a Subnet to the C-Chain.

It's the opposite direction where we apply this optimization because Subnets usually have a much smaller validator set than the Primary Network (and the Primary Network validator set used to place an upper bound on the size of the Subnet's validator set). When a Subnet receives a message from the Primary Network, the most obvious solution is to require a threshold of stake from the C-Chain (Primary Network) validator set. However, if the Subnet validators are already syncing the C-Chain, then we can do something a little bit different. A Subnet already assumes that its own validator set is at least 67% correct, so we instead require an aggregate signature from the receiving subnet's validator set.

So if a message is never actually sent from the C-Chain, an attacker will never be able to create a signature with a sufficient threshold of stake on the receiving Subnet unless it was already compromised.

If the message is sent on the C-Chain, then the Subnet can produce a signature with its own validator set and does not need to aggregate a signature from the much larger Primary Network validator set.

Thanks for the explanation. Will we continue to use the term Primary Network (as defined in current Avalanche docs as x, c, and p chains)? Perhaps I've misunderstood from a recent youtube video on acp-77 that the P chain is/will-be the only 'special' chain, i.e. all others will be subnets that rely on the P-chain and only the P-chain.

The Primary Network consists of all the chains validated by the Primary Network validator set, which includes the X/P/C chains.

This has been added with RecoverSubnetTx: https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/77-reinventing-subnets/README.md#recoversubnettx

I've created a PR to address the confusion with SetSubnetValidatorManagerTx here

This needs the full specification for the warp message included in the transaction rather than just listing the fields. It currently does not specify the payload type (AddressedCall) or where the listed fields should go within the nested payloads

This is in Step 1: https://github.com/avalanche-foundation/ACPs/blob/218b62f4dd907f80f5991455dddcf72d59f33bb6/ACPs/77-reinventing-subnets/README.md#step-1-retrieve-a-bls-multisig-from-the-subnet

Should we repeat it in Step 2?

There is no specification for the Warp message produced by the P-Chain to notify a Subnet of the action

Need to notify the Subnet of removal, so that it can respond with a SetSubnetValidatorWeightTx or else this results in a permanently offline validator

For both of these, the exact mechanism is still being worked out through implementation so it's under-specified on purpose. I'll update the ACP noting that.

This changes the semantics of current PoA Subnets where a specific control key has control of the Subnet to allow the validator set to take it over permanently by issuing this transaction. I think it would make more sense to have a separate transaction used to transfer subnet ownership from a control key to a Warp Derived Address. By separating the functionality out, there is no need to construct a bastardized warp message offline and the PoA control key retains control of the validator set until it explicitly transfers that control.

That's correct. I've talked to a few Subnet operators (AvaCloud and GoGoPool) and they were comfortable with this approach. I'm not as concerned with the "bastardized" warp message as the validator set is the one in control here, not the smart contract.

With the latest changes to ACP-77 to separate storing the validator in-memory to flushing it to disk, so that it is effectively offline without changing the validator set itself, should there be a separate cost for long term storage? We probably need some way to clean this data up as well at which point we may come back to the same issue.

The initial 5 $AVAX balance is the separate cost for long term storage. This is discussed here: https://github.com/avalanche-foundation/ACPs/blob/218b62f4dd907f80f5991455dddcf72d59f33bb6/ACPs/77-reinventing-subnets/README.md#security-considerations