ACP-13: Subnet-Only Validators (SOVs) #14
Replies: 13 comments 3 replies
-
A draft of this ACP was posted on in the "Ideas" Discussion Board, as suggested by the ACP README. Some feedback on this draft was collected and addressed on both the "Ideas" Discussion Board and on HackMD. |
Beta Was this translation helpful? Give feedback.
-
This looks great! What is the thinking around choosing Do we lose anything by going lower? It seems like it'd be maximally helpful to Subnet to have the SOV bond be around 100 or 250 AVAX. |
Beta Was this translation helpful? Give feedback.
-
The Block posted about this ACP here: https://www.theblock.co/post/260139/ava-labs-proposes-astra-upgrade-to-bolster-subnet-architecture-on-avalanche They are using the terminology "Astra Upgrade" because I've been referring to this wide-ranging and likely to be long-running track of rethinking the relationship between the Primary Network and Subnets as "Astra". |
Beta Was this translation helpful? Give feedback.
-
If you don't mind me thinking out loud: if the P-chain becomes the "primenet" but still requires X and C to be validated in the same set, these two would, in my opinion, feel "bolted on" for legacy purposes rather than actually being relevant. While the P-chain provides clear value to validators (specially if the PAYG AVAX is partially distributed as rebates rather than just burnt), there has to be some use for X/C-chain to justify their existence moving forward. I thought about a few things that could help each chain pull their own weight by making them all work in tandem: P-chainThe P-chain probably doesn't need any justification to exist, as it already kind of exists as the "primenet". It's what helps coordinate all validators of all networks, including itself, which is pretty cool, but I digress. Its role in the "triad" that is the Primary Network should be keeping relevant data about every node in the network, and I think that is all it should do. Maybe my information on the docs is outdated, but AFAIK, it can also handle the emission of assets created on the X-chain, which is kinda weird. It also "custodies" assets that were previously held in the other two chains (at least that's my understanding of what "exporting" AVAX or similar does). In my opinion, it should do only one thing and do it well, and for that, we would need to modify the other two chains so they have a more relevant roles inside of the Primary Network, which I will discuss in the following paragraphs. X-chainThe idea of the X-chain was neat, but it didn't work all that well in practice. I still think it would have added something "unique" to the network with the DAG architecture, but now that it's been linearized it is pretty much a "worse" C-chain, but with the ability to issue assets for the rest of the network. In the new model, I think the X-chain should be the sole authority issuing (save for maybe $AVAX, which is a special case) AND CUSTODYING assets. This means that, instead of the current model where you transfer your assets to the other subnets by burning and minting on the other chain, it should allow for smart escrows or bonds where you give authority to other subnets to use those assets within some previously agreed parameters. For example, you could issue a 2000 $AVAX X-chain bond for the P-chain to use for your validator, and then generate a recipe via AWM of the existence of that bond to be used by the P-chain. But how to handle complex emission schemes or potential slashing via the X-chain when all you have is a bond? We will need the C-chain for that. In addition, the X-chain could also work as a way to broadcast and/or pin AWM messages from different subnets by storing them as an NFT. It's the eXchange chain, after all. C-chainThe C-chain is excellent for general computation. In this scheme of the "triad", the C-chain could be the bespoke CPU of the Primary Network: both P-chain and X-chain should know intimately about it, and may specify that some parameters of their computations depend on the results from a C-chain call. Say, for example, instead of specifying emission rates by either contemplating every single possible parameter of a curve or allowing people to upload their own formulas, the emissions field of a subnet in the P-chain could simply have a pointer to a payload for the C-chain to emit an AWM-signed message for the results of that computation (i.e. calculate MaximumSupply depending on the results of a smart contract call). For this to work correctly, though, the C-chain should also feature some way for subnets to have their own accounts in the C-chain and have some way to pass on the gas fees to the subnet account, either via some special precompile or by implementing a "reverse charge call" EVM opcode to have full account abstraction in smart contracts. The C-chain could also act as a mediator on how to resolve bonds from the X-chain by aggregating AWM with special logic and deciding on how to spend the UTXO (i.e. the P-chain emits the statistics of the validators as an AWM, and the C-chain determines if the validator has to be rewarded or slashed, and how). In additionAll these measures would make the Primary Network tightly coupled, working in tandem, where no chain is a "legacy dead weight". It would also encourage burning/redistribution of AVAX by charging for these computations, either by requiring subnets to pay AVAX to generate AWM or by burning gas with the C-chain hooks. As an addendum, I propose that Primary Network validators be able to validate Elastic Subnets and earn rewards by letting them opt-in to tying their entire Primary Network staking rewards to correctly validating all the Elastic Subnets the node is part of. This way, the security of a subnet can be kickstarted without requiring the validators to make a huge upfront investment (or a token at all!), and it would also make more sense than requiring validators to pay for the privilege to give themselves work. |
Beta Was this translation helpful? Give feedback.
-
Since the fee is refundable and transaction costs are minimal, there should be a minimum period set. honestly, I think the simplicity of a fixed amount is best but scaled amounts might sit better in dealing with the question of how does it affect the stability of the network |
Beta Was this translation helpful? Give feedback.
-
Imagine what the internet would look like today if everyone who ever created a website needed to post a $5k bond. I think the goal should be to make the barrier to entry as low as possible. Make p-chain validation optional for subnet-only validators -- subnets can rely on the security of the primary network to track changes to their validator set, if they choose. Then, the AVAX staking requirement can be zero for subnet-only validators. This would make Avalanche the ISP of this next phase of the internet, by only charging AVAX to track every subnet's participants and route AWM messages, nothing else. If there is a limitation preventing this, I would be interested to learn about it. I also recommend to give this ACP a new number before implementing it. The current one is bad luck. |
Beta Was this translation helpful? Give feedback.
-
So, if I'm understanding this correctly, individual nodes cannot have SOV contracts with SLAs for resource renting with individual SOVs because proving the guaranteed resources were delivered per the SLA is a difficult and possibly intractable problem? This is why you need to go with the resources lent by the entire network approach rather than set up a market by individual node operators? |
Beta Was this translation helpful? Give feedback.
-
Another use case, and a current restriction, at PLAYA3ULL GAMES we sell "master node" licenses which will be later used to build a dedicated gaming network. The issue of having to stake 2k AVAX and the compute requirements of validating the C-Chain, is it completely removes the potential to use those users (5.5k nodes who are ready to run a network) with Subnets. I know this is a very specific use case, but we also hear there are others who are looking at other similar networks in the space. @gatesyp Maybe there is a hybrid approach, where subnets that already have validators that are able to run SOVs, or form another subnet that can have SOVs. Specifically to us, we currently have 5.5k nodes, that are ready form a decentralised network tomorrow if instructed to do so, I could imagine a use-case where HyperSDK and SOVs would form a super lightweight network. We currently have a barebones EVM network, which has no customisations to it. We're super excited about this concept, especially looking at HyperSDK as well. |
Beta Was this translation helpful? Give feedback.
-
What is the objective of lowering subnet requirements? To have more developers experimenting on real world blockchain solutions. I think the same strategy should be considered with lowering the financial requirements. Temporarily lower the AVAX requirements, let new use cases evolve, and then watch as institutional subnets rush to build their own. 1-2 year trial then back to 2000 AVAX |
Beta Was this translation helpful? Give feedback.
-
"Fees paid to the Avalanche Network for PAYG could be burned, like all other P-Chain, X-Chain, and C-Chain transactions, or they could be partially rewarded to Primary Network Validators as a "boost" over the existing staking rewards. The nice byproduct of the latter approach is that it better aligns Primary Network Validators with the growth of Subnets." I agree with your vision for PAYG for the most part. I'm very much in favor of a transition to a dynamically priced, continuous payment mechanism to register as a Subnet Validator. I can imagine a world where X and C chain are just two of thousands of subnets. In that world, it's likely that there will be subnets far larger than the X or C chain. It would be weird for subnets to be paying a tithe to "just another subnet(C chain)", for no purpose other than alignment. Your initial thought of burning all Fees paid by subnets is the best one. P-chain becomes the core of the network and everything else are just subnets with interoperable and streamlined communications. In this vision, what becomes of $AVAX?
Concerns: In order to secure the P-chain, AVAX will have to retain substantial value. I'm not sure that the above use cases provide enough AVAX value to secure the network in the short term before mass adoption. Yes, it is securing it now. Currently, let's be truthful, most of the monetary value of AVAX is coming from speculation, which is unstable due to its cyclical nature. Will speculation be enough security until adoption sustains it's value function? What are your thoughts? |
Beta Was this translation helpful? Give feedback.
-
"I can imagine a world where X and C chain are just two of thousands of subnets. In that world, it's likely that there will be subnets far larger than the X or C chain. It would be weird for subnets to be paying a tithe to "just another subnet(C chain)", for no purpose other than alignment. Your initial thought of burning all Fees paid by subnets is the best one." Additionally, in this vision, it doesn't make sense to only pay AVAX rewards to X-P-C-chain validators, if C-chain is just another subnet. Consider this:
This is a major re-visioning, but I believe it's much closer to a sustainable future for the ecosystem. With the speed and ability Avalabs has show it can ship innovation, I believe something like these changes could be implemented by Summit III. What do you think? I'm very much open to being wrong. Strong beliefs, lightly held. |
Beta Was this translation helpful? Give feedback.
-
SOV seems right to me and will help the sub-network ecosystem to grow rapidly. Why not to require one primary network validator? |
Beta Was this translation helpful? Give feedback.
-
ACP-13 has been superseded by ACP-77. As a result, this discussion is now closed. |
Beta Was this translation helpful? Give feedback.
-
Introduce a new type of staker, Subnet-Only Validators (SOVs), that can validate an Avalanche Subnet and participate in Avalanche Warp Messaging (AWM) without syncing or becoming a Validator on the Primary Network. Require SOVs to pay a refundable fee of 500 $AVAX on the P-Chain to register as a Subnet Validator instead of staking at least 2000 $AVAX, the minimum requirement to become a Primary Network Validator. Preview a future transition to Pay-As-You-Go Subnet Validation and $AVAX-Augmented Subnet Security.
This ACP does not modify/deprecate the existing Subnet Validation semantics for Primary Network Validators.
https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/13-subnet-only-validators.md
Beta Was this translation helpful? Give feedback.
All reactions