ACP-77: Reinventing Subnets #78
Replies: 32 comments 102 replies
-
At Landslide, we are thrilled to see this ACP proposal and support it 100%. We are very interested in learning all the technical details, especially understanding: The possibilities are endless. Subnets now have full control over their validator set. Regarding subnet rebranding, we suggest "Avalanche L1s" instead of "subnets." Colloquially, we could say, "Landslide is an Avalanche L1". |
Beta Was this translation helpful? Give feedback.
-
PLAYA3ULL GAMES also fully supportds this. We currently have 6500 nodes that users have purchased, it would be amazing to be able to onboard them in some format to the PLAYA3ULL GAMES Subnet. Interested to see this evolve! |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Why is it mandatory to abolish the current system if this ACP is accepted ? That way the current subnets would have the choice to do it or not, it would give free will to the subnet that has trusted Avalanche up to that point. We would have two systems. One subscription format and another one with no fees but with a big initial bet. Any opinions ? Thank you for this ACP good job. |
Beta Was this translation helpful? Give feedback.
-
I really like the constraints this removes and the flexibility it introduces. It ticks a lot of boxes for me. It is not clear to me where the ownership to a specific contract is defined. It might need a minimum set of features such as 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. 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. |
Beta Was this translation helpful? Give feedback.
-
Awesome to see the changes discussed in several topics before formalized under an ACP! I am of course in favor of this as it will effectively enable PoS (and other kinds of) Subnets on Avalanche. Several questions:About $AVAX balances
About Backwards Compatibility
Suggested changes:I suggest the following changes for clarity: Sidebar: Subnet Sovereignty
Subnets renamingI cannot come up with anything else than |
Beta Was this translation helpful? Give feedback.
-
Could you explain what you are talking about regarding "target utilization" in the Continuous Fee Mechanism? Are you talking about composite validator resource capacity? Like CPU's are running at 66%? How are you going to determine a proper target? |
Beta Was this translation helpful? Give feedback.
-
As a layman and Avalanche enthusiast I understand that this proposal addresses several concerns simultaneously. For me, what stands out is the potential to onboard some of the estimated USD$220T - $660T worth of RWAs onto Avalanche. This would immediately propel Avalanche to the forefront of blockchains where it truly belongs from both a tech and leadership perspective. Consider the impact if say, an arbitrary 10% of RWAs were to be onboarded on Avalanche. I think the $AVAX 2000 up front sacrifice is a small price to pay compared to the growth that can be seen. The small continuous fee should be sufficient to compensate however, for sound $AVAX tokenonmics? To reiterate a previously mentioned concern, I am not sure how security would be maintained since I understand the deterrent to malicious actors to be the cost of such an attack. Finally, subnets seem to have almost full autonomy with this proposal. Perhaps rename to "Autonets" - Autonomous Networks. Does bring to mind "Autobots" from Transformers. Too cliched? :) |
Beta Was this translation helpful? Give feedback.
-
This is an excellent proposal and solves the issues that I brought up with ACP-13 in the previous discussion. Thanks. |
Beta Was this translation helpful? Give feedback.
-
The main network will remain a foundation ensuring stability and security across the entire network. For this network, nothing changes; it will still require 2000 AVAX. With the implementation of ACP-77, what will be the benefit of having a validator node on the main network?
Given that the yield is deflationary and rewards are also, individuals will have more incentive to become validators on subnets, as rewards will be better and incentives more plentiful. We may risk having a limited number of large validators, which could impose rather high delegation fees. |
Beta Was this translation helpful? Give feedback.
-
Hi Subnet community, the Beam team is working through ACP77 to align our PoS migration process with the latest info. Thanks for putting all the effort in! Three questions popped up which might be relevant for other subnets too:
|
Beta Was this translation helpful? Give feedback.
-
Great post, there are a few critical design decisions that I think need to be solidified here:
Who Pays FeesWho Pays Fees in Current ACP-77 Spec: UserACP-77 proposes that fees will be handled by the users behind Subnet validators, as outlined in the New Registration Flow section.
The transaction on the P-Chain could be completed by a separate entity, so that the user only needs to send a single transaction on the Subnet. However, the current design doesn't fully specify what signature or authorization is required to issue the If there's no protection that requires only the original issuer (or a pre-specified actor to authorize delivering the Warp Message), then a malicious party can deliver the Warp Message in its own transaction and set an arbitrarily low balance, so that the registered validator will get evicted quickly and the Warp Message will no longer be replayable. In this case, the user would be out of luck. We could set a minimum balance, so that an attacker would be required to specify some minimum amount, so the validator will not be evicted quickly and if the user wants to set a higher balance, then they can simply use an Preferred Alternative: Subnet Pays FeesI prefer an alternative path where the Subnet itself handles the fees. This removes the complexity of the user issuing multiple transactions. To do this, a Subnet would maintain a balance on its Warp Derived Address and authorize I prefer this approach because it more closely aligns with the value prop of building an L1 with Avalanche. If you are building an L1 on Avalanche, the value prop to your network is cross-chain interoperability. By streaming your validator set to the P-Chain and syncing the P-Chain state, a network built on Avalanche can connect to the rest of the ecosystem. This tradeoff makes sense for a Subnet when: value of interoperability > cost of registering and syncing the P-Chain As more networks launch on Avalanche, the value of interoperability on Avalanche grows and the Avalanche Ecosystem builds network effects. This can easily be a positive tradeoff even when a chain only connects to a small number of other networks. Imo this makes it critical that connecting with the P-Chain is both extremely low cost and extremely simple to integrate. As Avalanche continues to improve, we can continue to increase the target rate for P-Chain state consumption (potentially integrating DB improvements like Vilmo, so that we can switch from storing all validators in-memory to just the keys https://twitter.com/_patrickogrady/status/1780974444779098170) so that the continuous fee can remain low. As long as costs can be kept low by performance improvements to the P-Chain, it should be easy to make this equation true: value of interoperability > cost of registering and syncing the P-Chain. The larger barrier is most likely actually supporting Warp and changing the flow of creating new validators, so that users need to interact with the P-Chain at all. If we can avoid that user complexity and make it as easy as possible, then it will be much easier to onboard more networks to Avalanche. How Subnets Can Cover the FeesIf the Subnet pays instead of individual users, then the Subnet maintains an account balance on the Warp Derived Address, which the P-Chain can subtract fees from for both registering Subnet validators and to pay the continuous fee. If the P-Chain provides a facility to recognize who topped up the Warp Derived Address' balance on the P-Chain, then the Subnet can recognize and reward topping up the balance with a market mechanism - create a decentralized arbitrage opportunity anyone can capitalize on to ensure the P-Chain balance can continue to cover fees. In this case, the Subnet pays the continuous fee for ALL of its validators rather than forcing the user to issue a separate transaction and maintaining its own balance on the P-Chain. This has the added benefit of making the eviction path more robust. 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. On the other hand, if the Subnet pays the fees for all of its own validators, then the entire Subnet validator set would be evicted at once. The P-Chain would then handle this eviction by replacing the validator set with a merkle root, so that it can be revived from an inactive state. In this failure scenario, the Subnet is temporarily unable to send cross-chain messages while its validator set has been removed from the P-Chain (although it would continue to operate normally and could also verify warp messages by continuing to track the P-Chain state). This actually works out exactly as we would want. If the value from cross-chain activity are insufficient to cover P-Chain fees, then the network should not be willing to pay it. To handle this eviction path, the P-Chain would support a separate MigrationI don't think we can force all existing Subnets to migrate immediately. Existing Subnets launched on the existing PoA interface supported by the P-Chain and should have at least one network upgrade to switch over. Otherwise, I'd expect to see some Subnets have disrupted service if we took this path. In my opinion, it's much better to continue to support the PoA model at least through the E Upgrade. It's much more reasonable to deprecate Elastic Subnets since they have not gotten any adoption on mainnet. We should also clearly specify a migration path from a PoA Subnet to being controlled by a specific Warp Derived Address. Otherwise, it's unclear what address should control the Subnet's validator set on a go-forward basis. The nice part of using Warp Derived Address's is that the contract controlling a Subnet can be deployed to any chain including the C-Chain. I'd suggest adding a similar transaction to |
Beta Was this translation helpful? Give feedback.
-
Am I correct in saying that AVAX value does not secure the P-chain? AVAX is used to pay for usage of the Registry. The Security of the P-chain is provided by cryptographic proofs that limit any possible malfeasance to the security of the validator's subnet? Hence, if your subnet is secure, your security assumptions are based on the security of the subnets you interact with. Am I right? |
Beta Was this translation helpful? Give feedback.
-
I am wondering something about the Continuous Fee Mechanism: Imagine a Subnet with a huge validator set in the tens or hundreds of thousands being the sole responsible for most of the P-Chain load. Target utilization will be met or exceeded so the base fee will move up impacting smaller Subnets in their operational cost. I'm thinking of the recent inscriptions craze rendering a lot of EVM chains unusable for a lot of users because of gas fee spike. Is there a risk of something similar happening to the P-Chain? |
Beta Was this translation helpful? Give feedback.
-
I’m really surprised at how little engagement there is on these major proposed changes and what’s at stake. I appreciate Avalabs efforts to support this governance process. Everybody must be busy cheerleading their meme coins on Twitter/X :( Removing AVAX staking requirements for Subnets is a tectonic shift in tokenomics for AVAX. I’ve seen almost no one mention this in social media and the devs seem reluctant to talk about it in podcasts and forums. I'm concerned about the tokenomics of ACP-77 The previous narrative supporting it’s AVAX valuation was that Avalanche would have a massive number of subnets. These subnets would have to lock up AVAX for their Validators, thus locking up supply of AVAX in increasing amounts. This would increase the security of the system by having more and more TVL which could be used for secondary use cases, like Defi, re-staking, etc. Without staking requirements beyond just the P/X/C-chain, where is the new usage going to come from to justify functional level of token valuation? I only find 4 justifications put forward. Governance: I’m assuming that AVAX will still be the governance token for the P, C, & X-chain. d. Subnets using AVAX for their system token. There are a lot of benefits to having your own token. Namely, you can target tokenomics for your ecosystem’s needs and not be subject to the whims of another system that don’t pertain to your needs. With this given, I see little use for this potential value justification. What happens to AVAX value after ACP-77? Based on the rationale above, the value of AVAX should, in a rational market, reach a balance based on supply and P-chain usage(demand). How much value will accrue to AVAX, has to do with the cost per transaction that the market will bear, the frequency and type of transactions, the number of Validators, and the free floating AVAX supply. I simply don’t have the info I’d need to calculate this. Going Forward Options: This may be in your plans. Avalanche should also start another subnet with their fastest technology and promote its usage. It will be inspiring for devs to build on, Of course it would natively use AVAX. This would give the token a little more lifeline as demand shifts in the EVM mindshare. Sorry for the rough nature of this comment, I’m just trying to get it out there quickly with little time for editing. I’m truly inspired by Avalanches tech and vision, so don’t take these criticisms personally. |
Beta Was this translation helpful? Give feedback.
-
"ACP-77 needs to be accompanied by detailed modeling and simulation work on the Continuous Fee Mechanism (CFM) and other P-Chain fees based on subnet adoption and inter-subnet interaction to better understand the impact of this proposal on tokenomics." says :omer@demirelo on X and I agree. |
Beta Was this translation helpful? Give feedback.
-
This is a very major change in terms of how the avalanche network works and its tokenomics. By seperating the subnets from p chain, I can not see how the subnets can be thought as part of the network. This acp will make subnets independent of the main chain. As an indian proverb says "If You want to Walk Fast, Walk alone. But if you want to Walk far, walk together", the intention is to make subnets faster by eliminating the hot point, that is validating the p chain. I would kindly ask the avalabs to bring in a tokenomics expert to view the subject from a different point of view. Personally , with my limited knowledge I am against this proposal |
Beta Was this translation helpful? Give feedback.
-
What to call Subnets? Really they are just Layer Ones who use Avalanche tech for consensus and communication. Why call them anything but "Layer Ones". We can point out that it's Avalanche tech under the hood. "Layer Ones with secure and fast AWM." |
Beta Was this translation helpful? Give feedback.
-
My ideal #APower subnet should: ■ Pay cheapest possible $AVAX rent for P-chain use, Since $APOW inflation is already happening on the C-chain, I'd like to reward my #APower validators with: ■ part of the $APOW TX fees, where low subnet TPS would imply a high fraction of fees as rewards, and a high TPS a low fraction; ■ and AWM/Teleporter bridge tolls, where the toll tax should be progressive. |
Beta Was this translation helpful? Give feedback.
-
The primary motive /benefit of this acp seems to be lowering the 2000 avax barrier to 500 to become validator, this part could be seperated and implemented firs I assume, second part is beyond my technical knowledge, this also begs the question why not 100 avax or lower, this number appears to be dependent on the avax price, 80 k usd for current avax price is explained as a too high requirement for a low budget company to have its subnet,that means 500 avax may be high , should the price go to 160$ then we will have the same problem as we have now, that is that small gaming company will need 80K $ |
Beta Was this translation helpful? Give feedback.
-
Tokenomics: I think that subnet validators should be incentivized to hold some AVAX - like some exchanges where traders are incentivized to hold the exchange token. Otherwise it would be in the best interest of the subnet communities to keep the fees and the price of AVAX as low as possible. I could see the subnet validators having two options:
|
Beta Was this translation helpful? Give feedback.
-
Eth layer 2s are eating out of eth market cap, so will happen to avax, one can mint a coin in a subnet and claim it is as fast avax, he /she will be correct in saying that, if that coin is 1 tenth of avax price and do the same stuff, why would anyone need avax I havent had a reasonable answer to my question , why do you not lower that barrier with another acp independent of acp77, please dont tell me it was so in acp13 etc, you can seperate those two parts , entry barrier and subnets being independant chain, I see no need to have them in one acp |
Beta Was this translation helpful? Give feedback.
-
Increasing the duration balance requirement, is an option that achieves similar qualities to staking as an AVAX value sink, and skin in the game for subnets, but functions in the ACP-77 format. It gives increased flexibility for validators over the rigid structure of staking requirements. It also deters intermittent validator set expansion attacks. Simply increase the minimum balance for subnet validators. This would act as a good faith deposit without requiring “stake”, or validating P-chain for rewards. DHRUBABASU outlined the mechanism in a previous comment. For a 24hr minimum validator period… “If the current[P-chain fee] 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.” Using this method to adjust minimum balance requirements allows the protocol under ACP-77 to dial in a balance between healthy tokenomics for AVAX and product market fit for subnets. |
Beta Was this translation helpful? Give feedback.
-
is there a timeline or eta for this acp to go live on mainnet? |
Beta Was this translation helpful? Give feedback.
-
I was wondering how the payment of the fees for the subnet validators works in practice. Let's say I'm validating a subnet and I deposit 25 AVAX on the P-Chain to pay for the fees for a few months (because I'm too lazy to top it up every two weeks). In this situation, I would like to earn some interest on the deposit to pay part of the fees from the interest. That is, I would like to delegate the 25 AVAX to a node on the P-Chain. At the end of the staking period, I receive the staking rewards and the accrued fees are deducted from my P-Chain address. Would this be possible? If I deposit even more, I could pay all the fees from the staking rewards. |
Beta Was this translation helpful? Give feedback.
-
Here’s a new paradigm to consider that solves multiple issues. Imagine the following: X-P-C-chains are separated and their functions are disentangled.(Breath deep.) C-chain: It builds itself to be the Avalanche ecosystem hub as a Layer One EVM, the same as it is now. X-chain: It doesn’t seem to serve much purpose(I may be missing something here.). I suggest we just drop it or convert it to something useful like a native oracle service. If it sticks around, it gets it’s own token. P-chain: It’s sole purpose is to operate as the Validator Registry and closely related services for AWM enabled chains. AVAX remains it's native token.
Reasons: This requires P-chain/AWM beneficiaries to have skin in the game. It simplifies the token functions for X-P-C, allowing them to align token holders based on the chain's function. It aligns subnets with AVAX governance of P-chain.(Currently alignment is skewed towards C-chain) It makes staking cheap enough for mass adoption of P-chain. If these changes are to ever be made, it will be much easier to implement earlier in the design process. |
Beta Was this translation helpful? Give feedback.
-
Regarding renaming the subnets: What about Avachains? Keeps the avalanche tech branding in, makes it clear it is a blockchain, and it removes the subordination implied by the word "SUB"net. |
Beta Was this translation helpful? Give feedback.
-
Thanks to everybody involved for helping to move Avalanche forward. Few observations mainly from economic perspective regarding this very fundamental change that is being considered ... In my view the fee model should meet the following criteria:
Importance of economics
Accessibility of creating a subnet Predictability of costs Conclusion |
Beta Was this translation helpful? Give feedback.
-
Potential Attack: Undermining Subnet Consensus with SpamProof-of-Stake (PoS) security derives from the assumption that some percentage (typically > 66%) of the staked/voting token supply is honest. Additionally, it is typically assumed that it is prohibitively expensive (not enough liquidity), not economically rationale (given the TVL-at-risk), or impossible (based on the token distribution) for a malicious party to acquire enough of the token supply such that they can cause a consensus failure. The proposed "Continuous Fee Mechanism" makes it more difficult to evaluate the security of a PoS Subnet using this commonly understood model. To register as a Subnet Validator, an operator must maintain some balance of $AVAX that pays a continuous fee for occupying space in the P-Chain state. This fee varies based on the number of Subnet Validators registered over all Subnets. When a Subnet Validator's balance reaches 0, they are forcibly evicted from the Subnet set. This set is used during consensus and during Avalanche Warp Messaging (AWM) verification on other Subnets. So, what's the issue? Instead of acquiring a large amount of a Subnet's token supply (which may not be possible or may be very expensive), I can now spam the P-Chain with Subnet Validator registrations (on any Subnet) to drive up the fee paid by all Subnet Validators. If some valuable Subnet (measured by TVL-at-risk) has a number of Subnet Validators with low $AVAX balances (i.e. they are trying to minimize idle capital), it may be possible to cost-effectively and quickly evict a large amount of stake from a Subnet using (potentially a small amount) of $AVAX fees. This could allow a savvy attacker to then takeover the Subnet with potentially far less of a Subnet's token than they otherwise would've needed without this dynamic mechanism. If fees were fixed (or a "bond" was used where fees were "paid" by not staking $AVAX), this attack wouldn't be possible. Before this mechanism is deployed, I think more time should be spent evaluating the cost of this "eviction attack." It may be necessary to bound the rate of fee increase (to allow Subnet Validators at risk to react), to introduce other safeguards (as a continuous attack could require operators to swap large amounts of the Subnet token supply to $AVAX to prevent eviction), and/or provide guidance that Subnet Validators should maintain larger balances to better defend against unplanned eviction. |
Beta Was this translation helpful? Give feedback.
-
In the current model, when a Subnet is communicating via Warp with the C-Chain, only the validators that validate the Subnet are asked to sign warp messages on the C-Chain. This is a nice optimization. Post-ACP77, since the Subnet and the C-Chain will not (necessarily) have any validators in common, how will the C-Chain signers be chosen for warp messages? |
Beta Was this translation helpful? Give feedback.
-
Overhaul Subnet creation and management to unlock increased flexibility for Subnet creators by:
This ACP supersedes ACP-13 and borrows some of its language.
https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/77-reinventing-subnets/README.md
Beta Was this translation helpful? Give feedback.
All reactions