Rethinking the requirements for subnet validators #10
Replies: 8 comments 49 replies
-
|
Frankly, I think paying 2000 AVAX for projects that build subnets in the network is a good way to ensure that the projects in the subnet are elite. I think the main thing to focus on is that the current validators in the network why stayed away from being a subnet validator. Because subnet projects want astronomical investments in their own projects and they do not take into account the expectations of validators. |
Beta Was this translation helpful? Give feedback.
-
|
I personally agree that the 2k AVAX requirement is burdensome to new developers looking to spin up their own networks. In a world where appchain stacks are becoming more prevalant, it makes little sense for Avalanche to try to gate its superior tech offering. I wrote a thread here highlighting these thoughts but IMO replacing the 2k AVAX requirement with a continuous fee would lower the Capex of starting a subnet and actually bring more utility to AVAX. |
Beta Was this translation helpful? Give feedback.
-
|
a publicly accesable validator-subnet market is needed much more |
Beta Was this translation helpful? Give feedback.
-
[Draft Proposal] The Path to 100k Subnets: Overhauling the Relationship between the Avalanche Primary Network and SubnetsOver the last few months, I've spent a lot of time thinking about what changes could be adopted on the Avalanche Network to make Subnets even more attractive to developers (especially new startups/ecosystems just getting started). I think that the most impactful change to consider right now, as you alluded to, would be overhauling the relationship between Subnets/Subnet Validators and the Primary Network. I typed up some background on this topic for those unfamiliar and shared a three-step rollout plan that IMO would better position Subnets in the increasingly competitve "launch your own blockchain" space (could be cleaned up and turned into an ACP). It is worth noting that I also think native interoperability with the Primary Network is critical to attracting developers to Subnets but didn't feel it was worth elaborating on because that functionality will be provided shortly via the Avalanche Warp Messaging (AWM) integration with the C-Chain and the launch of Teleporter. TL;DR, this will allow Subnets to use $AVAX or $USDC as their native token without a trusted intermediary. BackgroundEach node operator must stake at least 2000 $AVAX (~$20k at the time of writing) to first become a Primary Network validator before they qualify to become a Subnet Validator. All Subnet Validators, to satisfy their role as Primary Network Validators, must also allocate 8 AWS vCPU, 16 GB RAM, and 1 TB storage to sync the entire Primary Network (X-Chain, P-Chain, and C-Chain) and participate in its consensus, in addition to whatever resources are required for each Subnet they are validating. Although the fee paid to the Primary Network to operate a Subnet does not go up with the amount of activity on the Subnet, the fixed, upfront cost of setting up a Subnet Validator on the Primary Network deters new projects that prefer smaller, even variable, costs until demand is observed. Unlike L2s that pay some increasing fee (usually denominated in units per transaction byte) to an external chain for data availability and security as activity scales, Subnets provide their own security/data availability and the only cost operators must pay from processing more activity is the hardware cost of supporting additional load. Regulated entities that are prohibited from validating permissionless, smart contract-enabled blockchains (like the C-Chain) can't launch a Subnet because they can't opt-out of Primary Network Validation. This deployment blocker prevents a large cohort of Real World Asset (RWA) issuers from bringing unique, valuable tokens to the Avalanche Ecosystem (that could move between C-Chain<>Subnets using AWM/Teleporter). Elastic Subnets enable projects to secure their Subnet and incentivize Subnet Validators with a custom staking token. However, there is no way for the broader Avalanche Community to augment the security afforded by these custom tokens with $AVAX to help bootstrap new ecosystems (which may otherwise not have enough value at stake to secure meaningful TVL). Proposed Rollout of Subnet ImprovementsStep 1: Subnet-Only Validators + Subnet $AVAX Bonding
Without the requirement to validate the Primary Network, the need for Subnet Validators to instantiate and sync the C-Chain and X-Chain can be relaxed. Subnet Validators will only be required to sync the P-chain to track any validator set changes in their Subnet and to support Cross-Subnet communication via AWM (see “Primary Network Partial Sync” mode introduced in Cortina 8). The lower resource requirement in this "minimal mode" will provide Subnets with greater flexibility of validation hardware requirements as operators are not required to reserve any resources for C-Chain/X-Chain operation. The value of the required "bond" (X) is open for debate. To avoid impacting network stability, I think it should be at least 250-750 $AVAX. To set this "bond" lower, I think the PlatformVM should be futher optimized (assumes that lower fees lead to a corresponding increase in Subnets). Step 2: Improve PlatformVM Efficiency + Pay-As-You-Go Subnet Validation Fees
To increase the P-Chain capacity for processing Subnet reward distributions (which should allow fees to be parameterized more aggressively), we first should replace Proposal Block-based voting (1 Subnet reward votes per block) with BLS Multi-Signature voting (N Subnet reward votes per block). In a future state, this mechanism may allow Subnets to implement arbitrary reward mechanisms by adding an "amount" to this signed message instead of relying on the $AVAX reward curve that is currently used by all Elastic Subnets. @StephenButtolph has a number of ideas about this approach 👀. Once this vote processing change is implemented, it would be possible to just transition to a lower required "bond" amount, but many (myself included) think that it would be more competitve to transition to a dynamically priced, continuous payment mechanism. This new mechanism would target some $Y nAVAX fee that would be paid by each Subnet Validator per Subnet per second (pulling from a "Subnet Validator's Account") instead of requiring a large upfront lockup of $AVAX. The rate of nAVAX/second should be set by the demand for validating Subnets on Avalanche compared to some usage target per Subnet and across all Subnets. This rate should be locked for each Subnet Validation period to ensure operators are not subject to suprise costs if demand rose significantly over time. All fees would still be paid to the network and burned, like all other P-Chain, X-Chain, and C-Chain transactions. The optimization work outlined here should allow the min rate to be set as low as ~512-4096 nAVAX/second (or 1.3-10.6 $AVAX/month). Step 3: $AVAX-Augmented Subnet Security
Currently, the only way to secure an Elastic Subnet is to stake its staking token. Many have requested the option to use $AVAX for this token, however, this could easily allow an adversary to takeover small Elastic Subnets (where the amount of $AVAX staked may be much less than the circulating supply). $AVAX-Augmented Subnet Security would allow anyone holding $AVAX to lock it to specific Subnet Validators and earn Elastic Subnet reward tokens for supporting honest participants. Recall, all stake management on the Avalanche Network (even for Subnets) occurs on the P-Chain. Thus, staked tokens ($AVAX and/or custom staking tokens used in Elastic Subnets) and stake weights (used for AWM verification) are secured by the full $AVAX stake of the Primary Network. $AVAX-Augmented Subnet Security, like staking, would be implemented on the P-Chain and enjoy the full security of the Primary Network. This approach means locking $AVAX occurs on the Primary Network (no need to transfer $AVAX to a Subnet, which may not be secured by meaningful value yet) and proofs of malicious behavior are processed on the Primary Network (a colluding Subnet could otherwise chose not to process a proof that would lead to their "lockers" being slashed). This approach is comparable to the idea of using $ETH to secure DA on EigenLayer (without reusing stake) or $BTC to secure Cosmos Zones on Babylon (but not using an external ecosystem). Security Considerations
AcknowledgementsThanks to @luigidemeo1, @StephenButtolph, @aaronbuchwald, @dhrubabasu, and @abi87 for their feedback on these ideas. |
Beta Was this translation helpful? Give feedback.
-
|
Source: #10 (reply in thread)
AFAIK it is not possible for a PNV to provide "comms and consensus" without also running a Subnet's Custom VM binary themself. Recall, the VM binary informs the consensus engine, amid a bunch of other things, whether or not a block is properly formatted (i.e. "ParseBlock") and whether or not a block is valid (i.e. "VerifyBlock"). It would be possible, in this structure, for a rogue RPC to incorrectly communicate the result of either of these calls and the PNV could end up voting or even accepting an invalid block (which shouldn't be possible). The issue, more concisely put, is that consensus invariants are currently upheld by both AvalancheGo and Custom VMs (and I'm not sure it would be possible to decouple them because some checks require access to Subnet state). Note, I'm not addressesing the scenario where a rogue PNV modifies the responses with something incorrect because that would be the same as a plain consensus failure (whereas the example I provided is a consensus failure that the validator unknowingly commits). Assuming that the Subnet creator is running this RPC, you may argue that they would never do such a thing. However, the whole point of the Subnet architecture is that an operator couldn't do such a thing (assuming code is not malicious). When the creator controls all the "VM hardware", it doesn't matter how many PNVs running the Subnet as security is not improved via replication (as "VM hardware" still can corrupt consensus). If you instead intended that some collection of pseudo-Subnet Validators would run these hardware instances (so the Subnet creator doesn't control them all), it seems odd to circumvent the built-in uptime mechanism with an out-of-protocol, market-based mechanism that intends to do the same thing (assuming it would also attempt to penalize this sort of behavior). Not to mention that fault attribution would be twice as complex and require checking both the RPC operator and on the PNV, rather than just a single entity (so all messages would likely need to be signed by the RPC operator and wrapped by the PNV). It seems cleaner/safter to just minimize the non-Subnet related responsibilites of a Subnet Validator such that it gets close to mirroring "just the hardware" and the on-chain fee as close to what the "PNV" could conceivably charge without losing money (goal of Step 1+2). I think there should be additional work put into better distribution (Subnet creator + n others could upload a signed binary to some source and it would auto-download) and isolation (run in a Docker container with scoped access to disk) of Custom VM binaries (seemingly some of the inspiration for this feedback). However, I think that convo is best reserved for a separate thread. |
Beta Was this translation helpful? Give feedback.
-
|
Source: #10 (reply in thread)
This is an interesting suggestion that I hadn't yet considered. Rewards, at least right now, are distributed "all or nothing" at the end of each validator's staking period. There is no notion of "accrued rewards" that can be used for this payment (it is unknown whether a reward will be distributed until the end). I guess some % of this reward could be "held" for this purpose but I'm not sure that would reduce taxable events (could be seen as a reward + transfer handled by the network). If the reward mechanism is changed such that rewards are "partially locked in" as the staking period progresses, it would be possible to introduce something like this (complexity aside) where the required contribution is stripped from the reward before it is "distributed". Again, I'm no lawyer so not sure if this would actually achieve the goals you alluded to. A more practical idea could be to allow these fees to be pulled from a Primary Network validator's stake. This would allow all idle $AVAX to be staked without needing to worry about manually reloading a "fee paying" account on some regular cadence (reminds me of a yield-earning checking account that you hook up to a credit card). |
Beta Was this translation helpful? Give feedback.
-
|
Source: #10 (reply in thread)
While this is an interesting idea, there is no way currently to enforce (via the Primary Network) that a Subnet adheres to any set of rules/performs state transitions a certain way (in this case, using "AVAX" to pay fees). This is one of the trade-offs of the Primary Network not providing security to Subnets; the Primary Network can neither prove/disprove anything about any Subnet. Recall, this Subnet independence is also why data from Subnets doesn't need to be sent to the Primary Network and why Subnets don't need to pay fees as a % of their total usage. Even if you were to require proofs of some sort to be posted to the Primary Network from Subnets to take advantage of this "promo", it would not be possible to verify those proofs weren't forged (post proofs saying you were using $AVAX when you didn't). To roll this out (and ensure the Primary Network wasn't "ripped off"), you'd probably need to randomly assign validators to this network to avoid collusion by some group of "cheaters". This is a pretty far departure from how Subnets work today. |
Beta Was this translation helpful? Give feedback.
-
|
Over the last few days, I posted detailed responses to ~13 of the 60+ questions asked about this draft proposal. This was getting a bit hard to follow, so I created a @hackmdio for easier review (will dual-post): https://hackmd.io/@patrickogrady/100k-subnets#Feedback-to-Draft-Proposal |
Beta Was this translation helpful? Give feedback.
-
|
I ended up proposing an ACP based on this feedback: https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/13-subnet-only-validators.md We can carry on this conversation in the dedicated discussion channel for "Proposed" ACPs: #14 |
Beta Was this translation helpful? Give feedback.
-
Draft improvement proposal for Avalanche further decentralisation.
a) Set up the implementation process that depends on the subnet/network growth.
a) This keeps the validators honest. |
Beta Was this translation helpful? Give feedback.
-
@zybk70 Seems like Benqi's ignite product is about halfway there |
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.
-
|
I'll just add my thoughts that I like the direction this is going in. Having more of our hardware available for validating just DFK Chain would allow us to scale better. I also think this would lead to more subnets in the future. |
Beta Was this translation helpful? Give feedback.
-
|
This conversation is now locked. Any future discussion should occur here: #14. |
Beta Was this translation helpful? Give feedback.
and others
-
Context: I want to continue the discussion that has happened in various places in the avax community.
It's clear that the current subnet requirements are holding back the growth of subnets. Specifically:
These requirements are too burdensome in terms of cost and computation. With the latest developments of cross-subnet communication, it should be reasonable to start considering dropping these requirements.
web3 has a golden rule: value should accrue to the network of participants based on the value of their participation.
The primary network should accrue value based on the value of a subnet validators participation.
If all a subnet validator wants to do is register with the P-chain to be part of the network and validate the blockchain running their dapp, why is the primary network asking so much value accrual to happen back to itself (in the form of 2k avax requirement)?
What are the downsides to allowing subnets to join the network through registering through the p-chain, not validate the primary network, and pay a fee in accordance to their participation in the overall network?
Beta Was this translation helpful? Give feedback.
All reactions