ACP-77: Reinventing Subnets #78
Replies: 40 comments 116 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.
-
|
Given that a Subnet can have multiple blockchains, this might not apply to all. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
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.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I wrote a short thread discussing the 2000 $AVAX removal: https://twitter.com/dhrubabasu_/status/1784294145009524972 |
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
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.
-
This is a good point, we will likely need a
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))
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. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding burning fees versus distributing them as rewards: |
Beta Was this translation helpful? Give feedback.
-
|
I mentioned this in an earlier comment:
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. |
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.
-
|
+1 for "Avalanche Realms" |
Beta Was this translation helpful? Give feedback.
-
|
also have similar questions about the validator balances. i think having a "clear migration path" from permissioned subnets would also have great value! |
Beta Was this translation helpful? Give feedback.
-
|
ACP-77 does not introduce the Warp Derived Address that #73 discusses. The initial 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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
In ACP-73, there was a notion of transferring funds to the "Warp Derived Address".
The main delineation I was making with this comment is that the |
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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." |
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.
-
|
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. |
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.
-
|
Let's imagine a potential world where ...
Question about this scenario:
|
Beta Was this translation helpful? Give feedback.
-
|
This is an interesting scenario you’ve proposed. :
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. |
Beta Was this translation helpful? Give feedback.
-
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).
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
"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. |
Beta Was this translation helpful? Give feedback.
-
|
@jfsaine That is correct. Primary Network Validation is the only thing that results in new AVAX emissions. |
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.
-
|
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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.
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.
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
This perspective makes sense to me |
Beta Was this translation helpful? Give feedback.
-
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. |
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
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. |
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.
-
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.
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. |
Beta Was this translation helpful? Give feedback.
-
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.
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.
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 not a new "utility". It's a different format of something that is already required of subnets, except that no stake is needed. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
It's inappropriate to talk about price in a tech-focused forum. Please discuss it elsewhere.
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.
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. |
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.
-
There is currently no ETA. Fuji Activation will come before Mainnet Activation though so it will be a few months at minimum.
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.
There is no 500 min AVAX part in ACP-77. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
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.
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).
Why should this be the case? The P-Chain load per validator is relatively fixed |
Beta Was this translation helpful? Give feedback.
-
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! |
Beta Was this translation helpful? Give feedback.
-
|
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.
❤️ |
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I created the discussion as you suggested. It's called, "Disentangle X-P-C-chains. Inspired by ACP-77 #88" and is located #88 |
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.
-
|
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. |
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.
-
|
Thanks for the detailed description of the attack! @aaronbuchwald also mentioned a scenario in the same vein as this attack in an earlier comment:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
@dhrubabasu Apologies for not catching this earlier. Could you explain why that approach isn't sufficient to prevent such spam attacks? Also @RnSpartners said :
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
While Subnets may have options on how they recv messages from the C-Chain, how will |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
The Primary Network consists of all the chains validated by the Primary Network validator set, which includes the X/P/C chains. |
Beta Was this translation helpful? Give feedback.
-
|
I vaguely remember that we had discussed a coping mechanism for empty validator set, so that a recovery key/control key can add validators (or directly sign warp messages). Should it be a part of this ACP? |
Beta Was this translation helpful? Give feedback.
-
|
This has been added with |
Beta Was this translation helpful? Give feedback.
-
|
There seem to be a number of places that remain to be fully spec'd out. If any of these are intentionally left unspecified until implementation begins, could you clarify where that's the intent to make it easier to read? RegisterSubnetValidatorTx (https://github.com/avalanche-foundation/ACPs/blob/218b62f4dd907f80f5991455dddcf72d59f33bb6/ACPs/77-reinventing-subnets/README.md#step-2-issue-a-registersubnetvalidatortx-on-the-p-chain)
ExitValidatorSetTx (https://github.com/avalanche-foundation/ACPs/blob/218b62f4dd907f80f5991455dddcf72d59f33bb6/ACPs/77-reinventing-subnets/README.md#exitvalidatorsettx):
SetSubnetValidatorManagerTx (https://github.com/avalanche-foundation/ACPs/blob/218b62f4dd907f80f5991455dddcf72d59f33bb6/ACPs/77-reinventing-subnets/README.md#setsubnetvalidatormanagertx):
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. |
Beta Was this translation helpful? Give feedback.
-
|
I've created a PR to address the confusion with |
Beta Was this translation helpful? Give feedback.
-
Should we repeat it in Step 2?
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.
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.
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 |
Beta Was this translation helpful? Give feedback.
-
|
On the topic of a dynamic fee, could a TWAP fee smoothing mechanism help with some of the concerns with volatility of the fee price? Could stake-weighted fee tiers for subnet validators mitigate some of the attacks described like:
|
Beta Was this translation helpful? Give feedback.
-
|
How is the progress? Will it be ready by autumn? |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, First off, I really appreciate the direction ACP77 is taking in lowering the barrier to entry for Subnet creators. The idea of decoupling Subnet Validators from Primary Network Validators and introducing a continuous fee mechanism makes a lot of sense. That said, I’m trying to wrap my head around the continuous P-Chain fee structure. If I understand correctly, the fees scale with network activity. While this seems great for making things more accessible initially, I’m concerned that for Subnets with high traffic, the ongoing fees could eventually add up to more than the 2000 $AVAX upfront stake from the old system. Wouldn’t this make it less attractive for validators in the long run, especially for those managing busier Subnets? It feels like the cost could actually end up being higher than before, which could deter some people from becoming Subnet Validators. I’d love to understand more about how the fee mechanism is balanced to ensure Subnet validation stays affordable, even as demand increases. Are there any safeguards or future plans to address this concern? Thanks for all the hard work on this proposal, and looking forward to hearing your thoughts! |
Beta Was this translation helpful? Give feedback.
-
|
If the future holds application chains with high throughput, this might be a case for some Subnets. |
Beta Was this translation helpful? Give feedback.
-
|
ACP-77 continuous fee/dynamic fee is proportional to the number of validators in the P-chain (see here). In other words it's not related to the network load (say tps) in the subnet chain itself. So a high traffic in a Subnet does not affect validator fees in P-chain. It only affects if Subnets add validators to P-chain. |
Beta Was this translation helpful? Give feedback.
-
|
With the changes lowering financial commitment (POS) to become a subnet validator by removing the need to lock tokens on the P-Chain, I’m worried that Subnets might become more vulnerable to attacks. Could this lead to a situation where every subnet decides to be permissioned just to stay secure? That feels like it goes against the original idea of blockchain being open and decentralized. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, some subnets may end up being permissioned. It's up to each subnet to decide what validator set is appropriate for the applications they support. This doesn't go against the original idea of blockchain, in fact quite the opposite. In the real world, organizations have strict compliance requirements. By allowing flexibility in subnet management, Avalanche can onboard new asset classes that otherwise would have never been able to exist on a blockchain. These assets can then have the ability to interact with the rest of the Avalanche network, and gradually become more open and permissionless over time. |
Beta Was this translation helpful? Give feedback.
-
|
Hi team, I was discussing with team members about new ideas to help $avax increase in value. For an Utility/Gas token like $Avax, I think it is important that its value remains directly link to the usage of the Network (adoption of the Network) That's builders should pay different gas fees to the P-chain according to the Tx Volume that they have on their permisionless L1. What about making it directly proportionate to the Tx/s 👍: OR either way We can turn it as an incentive instead of fees : 100Tx/day : stake 1 Avax along the Foundation in a shared node Eitheir way would help to burn or stake more $Avax as the L1 grow in throughput... Let me know what you guys think ? Kind regards, |
Beta Was this translation helpful? Give feedback.
-
Doesn't this ultimately incentivise the subnet operator to extract the additional cost of p-chain rent from their own subnet users either via mev, gas costs, or fees on swaps? Unless you'd expect that most subnets would be running at a profit anyway and therefore this change might just force operators to run at lower margins? If the cost is extracted by necessity it's akin to setting a 0.01 avax flat fee on every transaction on every subnet, which becomes a major barrier to adoption. |
Beta Was this translation helpful? Give feedback.
-
|
I guess the staking approach looks more attractive right ? |
Beta Was this translation helpful? Give feedback.
-
|
Hi team, I was discussing with team members about new ideas to help $avax increase in value. For an Utility/Gas token like $Avax, I think it is important that its value remains directly link to the usage of the Network (adoption of the Network) That's builders should pay different gas fees to the P-chain according to the Tx Volume that they have on their permisionless L1. What about making it directly proportionate to the Tx/s 👍: OR either way We can turn it as an incentive instead of fees : 100Tx/day : stake 1 Avax along the Foundation in a shared node Eitheir way would help to burn or stake more $Avax as the L1 grow in throughput... Let me know what you guys think ? Kind regards, |
Beta Was this translation helpful? Give feedback.
-
|
Creating arbitrary ways for value accrual is a difficult path to go in. The market has shown that blockspace is incredibly cheap and is getting much cheaper. If you take that assumption, the best method of value accrual is not to create arbitrary sinks for value that do not take into account the competition. This mechanism would have Avalanche take significant rent from aspiring L1s which would send them to Cosmos, L2s or whatever new solutions arise. Keep it simple and create a very strong network that can handle real scale. This will allow plenty of opportunities for value accrual via the C-chain + PAYG Fee mechanism. |
Beta Was this translation helpful? Give feedback.
-
|
$AVAX serves as a transaction fee within the Avalanche C-Chain ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding this change to prevent the last validator from leaving a subnet: #146 (comment) Does this mean that if the last remaining PAYG validator runs out of AVAX to pay the fees, it will NOT be removed from the validator set? So single-validator subnets are essentially "free"? |
Beta Was this translation helpful? Give feedback.
-
|
No, single-validator subnets will not be free. When a validator's balance hits 0, they will be marked as "deactivated" When a validator is deactivated they will not be tracked by the primary network for networking / bootstrapping, and they can not participate in WARP message production. This means the L1 will not be able to send or receive warp messages and operate effectively. In order to reactivate a deactivated validator, the balance must be increased with |
Beta Was this translation helpful? Give feedback.
and others
-
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