Elastic subnets and the bazaar #1765
Replies: 2 comments 9 replies
-
|
This is really interesting - and importan- discussion to have. Couple of thoughts: If the consensus weight is based on AVAX and rewards are weighted on the network specific token Doesn't it mean is very cheap to attack the network as an AVAX whale? Reason being, your AVAX stake won't necessarily lose value if it's a small subnet being attacked and the attacker doesn't have subnet tokens. So it would be the subnet token's holders that are harmed by the attack and not the attacker, who can profit from both the attack and the subnet token price going down. |
Beta Was this translation helpful? Give feedback.
-
|
I would agree that it would make it cheap to attack the network if you were already an AVAX whale - but maybe that's not a bad thing. AVAX holders have an interest in subnets thriving. Since these are permissionless networks, there may be subnets that AVAX Validators don't want operating. If someone created a decentralised marketplace as a subnet based on human trafficking - then yeah, i'd attack that. If someone creates a dogecoin subnet with both the bitcoin vm and an EVM running and i can earn fees, what's my incentive to attack? It's just like voting imo |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I see your point! Didn't understand fully at first. This could somewhat work for big non AVAX native tokens like BTC or Doge, where the alignment of AVAX holders with the network could be greater than that of the holders of the network's token. It might not work for smaller tokens that are AVAX native, but I guess that's not the point here |
Beta Was this translation helpful? Give feedback.
-
|
I have a couple questions:
In this world I don't really see what the distinct asset type is doing. In general, the only reason we have these assets is to provide sybil resistance... But if the sampling distribution is based on AVAX what does the distinct asset do on the P-chain? If we are trying to allow the VM to define the incentivization model, is there a reason that we shouldn't allow the VM to also define the sampling distribution? If we implement this - we could have a VM specify the AVAX token as a sampling model (as this proposal recommends)... But they could also implement some alternative sampling mechanism (even a PoW based mechanism) |
Beta Was this translation helpful? Give feedback.
-
|
Ok, gotchu. I'll explain my naive view of how something like this might be implemented and then explain why I think having the token locked on the pchain provides more value that just warping the asset in. bitcoin vm subnet:
So greater BTC.b stake grants you a greater fee share. Greater AVAX stake gives you greater weighting in consensus. The escalation of the network. The competition of validators for reward is rooted in BTC. The more BTC you lock up. The greater your share from the success of the network. The more BTC is unavailable to be sold in the market. It's a network a maxi can support because metcalfe's law (from an infrastructure/decentralisation pov not user) is based on their asset and not someone elses. Now while it may be simpler from a VM implementation to just say the proposer allocates the transaction fee to an address they control and there's no BTC.b lock up required to run a validator. You're pinning the growth of that network on a network the users don't necessarily care about or have any belief in. You have no faith that the validators of your network aren't adversarial to it because they have no skin in the game. If you believe that a subnet can be more valuable than the primary chain, you have to foster an environment where the rewards for accruing that asset are greater than the rewards for accruing your own asset. Or maybe it comes down to something as simple as bag holder bias. If you tell me that's unworkable from a consensus point of view, i'll happily concede the point - but hopefully i've conveyed some dynamics that i think would make that network more interesting. I'd love to hold some liquid staked btc.b 😍 |
Beta Was this translation helpful? Give feedback.
-
Ah - this was the key point I was missing. I'd like to pull this out into a few separate points/ideas (please correct anything that I misunderstood) My attempt at a summary
My thoughts on my own summary(assuming I did understand correctly)
I agree, the existing subnet staking mechanism is too restrictive and prevents innovative ideas.
I dislike that staking on the P-chain requires locking all rewards that can be allocated for the lifetime of the subnet.
There is no technical reason why the reward asset must be the same asset that determines consensus weighting. Up to this point, I agree with everything.
I don't know that rewards can be independent from consensus weight. Validators are being paid to secure the chain. A validator's consensus weight is the amount of responsibility they have. By separating these mechanisms, I'd be concerned that the network does not provide an incentive to secure itself.
Related to my point above, I don't know that rewards can truly be independent of the consensus weight... In my opinion, using AVAX as the consensus weight would actually prevent a subnet from being more valuable than the primary network. Specifically, because the security of the subnet would always be tied to AVAX. |
Beta Was this translation helpful? Give feedback.
-
I don't think they necessarily are independent. The security of the whole network, not just the subnet is already tied to AVAX. My assumption is that validators will secure the most profitable subnets available to them and attempt to minimise their own costs. As such, large AVAX validators already bear that increased responsibility. It becomes a question of, do they own enough BTC to make running the subnet profitable or not. That's going to be dynamic in the system, but in my mind if we establish the primary chain to be behaving cooperatively then it's possible to establish subsets would also behave cooperatively. Are the uptimes independent? If a validator is participating in consensus on 2 networks, does the failure to respond to one constitute a failure to respond in the other? |
Beta Was this translation helpful? Give feedback.
-
That's fair. I guess my hope would be that we wouldn't hardcode this mechanism as a subnet option - but instead allow a VM to somehow specify it.
It isn't really possible for the validator set of subnet A to measure the participation of validators in subnet B. There is still more work to be done around subnet uptime tracking... But only the validators of the subnet are able to form an opinion of their own uptimes. Those opinions however, can then be communicated to other subnets. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I agree on avoiding the hardcoding and abstracting out to allow the VM to provide as much of the mechanism as possible. While it may be interesting to track participation at the staked or consensus asset ID level, it would likely lead to false results if avalanchego evolved into more like cluster orchestrator piece. My preference would be that avalanche provides the most freedom on how you build your subnet. I'd rather things were tried and failed over being restrictive to known good solutions. Thanks for indulging my ravings in any case |
Beta Was this translation helpful? Give feedback.
-
The Cathedral
Subnets allow the creation of new networks to benefit from avalanche consensus and be supported by the large validator community that exists.
Elastic subnets being permissionless have been designed with similar parameters and reward mechanisms as the primary chain, in that the elastic subnet is created with the required incentivisation properties. While that doesn't prevent a subnet from creating it's own additional incentivisation's within the virtual machines, it does create a restriction in what kinds of assets can be used as the basis for a staking token. That restriction being assets that the p-chain has complete control over the supply.
To build an elastic subnet, you need an avalanche asset that you need to solve a distribution problem for.
The Bazaar
There are many existing coins and tokens with very good and wide distribution already established. Projects people believe in with communities, memes, subcultures, exchange support, AMM liquidity, p2p trading.
These communities don't always really use the token. Hodling is participating.
The problems with using these coins and tokens as staking tokens on new networks is
I would like to suggest that we allow these assets to be registered on the pchain as a distinct asset type with unknowable supply properties. You wouldn't be able to create an elastic subnet with this asset type but you could create a different kind of permissionless subnet that uses the token as a access guard for validating the subnet. Since the supply and distribution is unknowable for the pchain, the consensus weighting should be driven by the stake weighting from the avax on the primary chain.
Incentivisation for running a validator then rests on the virtual machine creator. We could have a BTC.b based subnet running a bitcoin vm where the transaction fees are split between validators based on the proportion of BTC.b they have locked up. The safety and liveness of the network would depend on the avalanche validator community rather than whether a bitcoin whale had entered yet. There likely will still exist times where the safety and liveness is attacked on some of these subnets but is it really a decentralised network if that wasn't a possibility.
Beta Was this translation helpful? Give feedback.
All reactions