A Step Towards Subnet Sovereignty + Improved DevX

[aaronbuchwald]

A Step Towards Subnet Sovereignty + Improved DevX

There's a clear need for Avalanche Subnets to maintain greater fault isolation, customizability, and sovereignty from the Avalanche Primary Network in order for the Avalanche Ecosystem thrive.

In my view, the three biggest drawbacks of managing all validator sets on the P-Chain are:

1. Reduced fault isolation (see ProposerVM Windower as one example)
2. Economic constraints on the creation of Subnets (See SOV Validators here)
3. Limiting validator set management to the rules set by the P-Chain (lack of customizability)

The alternative is simple. Subnets orchestrate their own validator set and notify the P-Chain of the updates. Validator sets gain full independence and keep the P-Chain up to date for cross-chain communication.

To achieve this, I’d propose that Subnets use a native staking module to manage their own validator set, and generate a Subnet Warp Signature to send the update to the P-Chain. The P-Chain can then verify the Subnet’s Warp Signature and execute the validator set update. To ensure staking integrators can handle everything in one place (one subnet), Subnets can additionally implement a standardized “Subnet Staking Request” executed via Warp.

Subnet Accounts

Subnet Accounts will be defined as an account owned by a Subnet itself (Subnet as a sovereign, group identity). Just like any other account, a Subnet account will be able to hold and own funds on any Subnet (addressed by their SubnetID) and sign transactions using Warp signatures.

Similarly to ACP-30, to implement Subnet Accounts, VMs will implement a trigger (send) and a handler (receive and execute). The key difference is that Subnet Accounts will sign transactions on behalf of the Subnet itself, so it will require a different access control mechanism than user initiated transactions (the trigger).

The handler VM will need to verify the Subnet Account Transaction signature and define what functionality is available to Subnet Accounts. This could be as simple as making Subnet Account Signatures a drop-in replacement or alternative to whatever signature schemes the VM uses, or separating out the functionality available to Subnet Accounts.

Subnet Orchestrated Validator Sets

Subnet Accounts will be used to implement a VM-native staking module. For example, the Subnet-EVM could use a precompile to implement Proof-of-Stake using its own native token. After a staking update is accepted, the staking module triggers a Subnet Account Transaction to notify the P-Chain of the validator set change.

Optionally, if there’s a desire to keep the Subnet validator set exactly up-to-date with the P-Chain, the Subnet can wait for a P-Chain lightclient to provide an acceptance proof before the Subnet's validator set actually updates.

Any other VM can implement its own staking module with custom staking logic if desired as long as the updates fit the specification for Subnet Account Transactions that can be executed on the P-Chain.

The simplest version of that interface and the fastest path would add a Subnet Account auth type to the P-Chain in addition to the existing secp256k1 feature extension. This would make Subnet Account signatures a drop-in alternative to secp256k1 signatures, allowing Subnets to sign any transaction type on the P-Chain.

In this model, the flow for creating a self-orchestrating Subnet would be:

flowchart TB
    A[Subnet Creator] -->|1. Create PoA Subnet| B[PoA Subnet]
    B -->|2. Transfer validator set ownership to Subnet| C[Sovereign Subnet]
    C -->|3. Issue Subnet Account Transaction to P-Chain| D[P-Chain]
    D -->|4. Confirm update via lightclient| C[Sovereign Subnet]

Loading

Note: this can also provide ERC-20 staking out of the box since the Subnet VM can implement a staking module that uses its own native token as the staking token. Subnets can then bridge their native token back and forth to the C-Chain via Warp.

This significantly reduces the scope of the P-Chain to the minimum required functionality for cross-chain communication.

Standardized Subnet Staking Request

One drawback of switching to Subnet orchestrated validator sets is that it creates multiple integration points for staking providers. Instead of managing liquidity, transaction fees, and staking rewards in one place (the P-Chain), staking providers would need to integrate each Subnet independently.

To reduce the friction for staking providers, a standardized cross-chain “Subnet Staking Request” can replace the single integration point.

For any two Subnets A and B that implement a standardized interface for "Subnet Staking Requests," the flow would be:

sequenceDiagram
    autonumber
    participant user
    participant SubnetA
    participant SubnetB
    participant P-Chain
    user->>SubnetA: become validator on SubnetB
    SubnetA->>SubnetA: DEX swap for required SubnetB native token
    SubnetA->>SubnetB: Subnet Staking Request on behalf of user (forward SubnetB native token)
    SubnetB->>P-Chain: issue validator set update to P-Chain
    P-Chain->>SubnetB: Confirm validator set update via P-Chain lightclient
    SubnetB->>SubnetA: confirm staking request
    Note over SubnetB: staking period completes
    SubnetB->>SubnetA: send back stake + reward at the end of staking period

Loading

This approach would also provide a huge unlock for liquid staking providers that want to use smart contracts to administer staking for both the Primary Network and Subnets.

Future Work

• Define the spec for new a new Warp payload type that denotes it came from the Subnet itself (rather than user initiated)
• Define the Subnet Account Transaction and Subnet Staking Request interfaces
• EVM/HyperSDK staking module implementations
• Build consensus on the right direction for providing subnet fault isolation and ERC-20 staking

Acknowledgements

Huge thanks to @luigidemeo1, @patrick-ogrady, @StephenButtolph, @dhrubabasu, @richardpringle, @joshua-kim, @michaelkaplan13, @ceyonur, @darioush, and @sm86 for their feedback on these ideas!

[gfkacid]

I like the rationale and overall support the idea!

One question I have: will the proposed implementation of Subnet Staking Request be dependent on Warp relays? And if so, what could the consequences be for introducing a dependency external to the network, for such a critical operation?

[aaronbuchwald]

Great question. There's no clear answer both have their tradeoffs and this would most likely be up to the VM as well, so we're really defining a good default here as opposed to making a decision on behalf of everyone here (this is very much a two-way door type decision). Using a relay is just the simplest way to do this to start the discussion, but we could make it much more robust as well.

Another possibility is for all of the Subnet validators to issue the update via their own P-Chain lightclient. Since it's the same transaction, issuing duplicates would be fine and the Subnet validators would just need to ensure that it hits the P-Chain mempool and then confirm when it gets accepted.

There's another edge case here around what happens if the P-Chain has dynamic fees and the fees start to rise as well as how should a Subnet pay for fees.

These both create a bit of complexity or potential ugliness, but are also very solvable problems, so I didn't mention it in the first post. Figuring out the best way to do this (again provided as a good default as opposed to locking anyone in to this mechanism design) would be part of the work necessary to take this from discussion post to a fully spec'd out ACP.

[Nuttymoon]

This is huge. It enables a LOT of use cases around staking and removes friction points of P-Chain staking (especially import/export).

I have a few questions:

1. Could we also envision enabling AVAX staking for the Primary Network directly from the C-Chain? This would greatly simplify the workflow for applications like liquid staking. But if I understand correctly the Standardized Subnet Staking Request cannot be applied to the Primary Network.
2. Would the validators' uptime tracking still happen on the P-Chain? And could other reward conditions (apart from uptime) be implemented at the VM level as well?

[aaronbuchwald]

1. There's no reason the Primary Network couldn't implement the Subnet Staking Request standard as well. If it's sufficiently useful to the community to enable generic execution that can trigger staking requests to any subnet including the Primary Network, then imo it makes sense to implement that standard on the P-Chain too.

2. For subnet orchestrated validator sets, imo it would make more sense to apply rewards on the subnet itself.

This enables greater customizability and is the more natural place to handle rewards for subnet orchestrated validator sets. In general, there's some functionality on the P-Chain that makes it so Subnets/VMs don't need to worry about it at all, but I think a better approach for a lot of cases is to provide good default open source modules that VMs can use to handle their own rewards.

For example, the uptime tracking in the P-Chain is handled by utilizing the validators.Connector interface defined here: https://github.com/ava-labs/avalanchego/blob/master/snow/validators/connector.go and then writing that information to disk throughout the lifetime of the node.

That's pretty simple functionality that could just as easily be attached to any VM. We could just as easily switch to providing good defaults for uptime/reward mechanism tracking in the VM, while still allowing it to be easily swapped out rather than depend on the P-Chain to handle it.

[Nuttymoon]

It's good to know that 1. can be implemented! And I agree that enabling custom reward mechanisms at the VM level would be beneficial. I like the idea of a bunch of standard modules from which Subnets can pick.

[aaronbuchwald]

100%. The idea of blockchains becoming a better coordination point for high quality open source software is extremely appealing to me.

I was particularly inspired by this blog https://words.filippo.io/full-time-maintainer/ to see how the world of open source is starting to change where top notch engineers like Filippo just can't get compensated by a single company commensurate with the value they're capable of adding.

[0xduality]

Thanks for proposing this! Can you clarify this part?

Optionally, if there’s a desire to keep the Subnet validator set exactly up-to-date with the P-Chain, the Subnet can wait for a P-Chain lightclient to provide an acceptance proof before the Subnet's validator set actually updates.

A subnet validator will have to run the P-Chain. Running the P-Chain means you can know whether the rest of the P-Chain validators accepted or rejected your proposed change. Why is a light client necessary here?

[aaronbuchwald]

This is an alternative to running the P-Chain at all. We want subnets to have complete fault isolation from the Primary Network. If every subnet validator uses their own instance of the P-Chain, then it's possible that they are a few blocks apart for a period of time. The P-Chain is ofc eventually consistent, but if there's an outage on the P-Chain, it's perfectly possible that two nodes see a slightly different last accepted block on the P-Chain until the issue is resolved. During that time, subnet validators that are using the proposervm will disagree on what a valid proposervm header is, which can cause issues on subnets.

There's a writeup here on some changes we've made to make it as unlikely as possible that this causes issues for Subnets even when the P-Chain is down: ava-labs/avalanchego#1292, but using a lightclient takes it from unlikely to unrelated, so that it cannot happen at all.

By using a lightclient instead, each chain updates its view of the P-Chain by using a proof that anyone can verify even if their own copy of the P-Chain may be at a slightly different point.

[0xduality]

Thanks for the clarification! Makes sense!

[smyyguy]

Interesting idea! So it seems that, in this model, subnet validators will still sync the p-chain but get more customization on how their validator set is created and managed.

How would this model pair with ACP-13, if implemented as proposed, to ensure the subnet validators make the 500 AVAX lock to become a Subnet only validator? Also, how would the P-Chain be assured the validator information for a particular Subnet is current? I am wondering if giving Subnets more freedom from the rules set by the P-Chain introduces a risk that the Subnet validators fail to update the P-Chain with the current validator set and stake weight and how that would impact AWM.

[aaronbuchwald]

Great question. To be 100% clear, this is a much more freeform approach and still in discussion phase, so I can only give my 2 cents on the best direction for the community here.

The right direction imo is to give Subnets full control of their own validator set, rewards, and determining the best fit for their own economic security.

In this model, they could utilize a 500 AVAX lock via a smart contract/program deployed on any chain in the Avalanche Network (C-Chain would be the natural place to start) and we don't need to push that functionality onto the P-Chain. The goal would be to keep the P-Chain as the lightest weight membership chain possible to serve cross-chain communication.

[aaronbuchwald]

As for ensuring the P-Chain validator sets are up to date, there are two possible approaches here.

The first is to simply allow there to be some delay between when a validator set updates and when that update is propagated to the P-Chain. As you pointed out, this carries the risk that the delay could cause issues with Warp.

Concretely, this becomes an issue if this creates a scenario where SubnetA sends a Warp message that SubnetB thinks is valid, but should have been invalidated because the validator set was already updated. The threat model where this causes an issue is the case that the previous validator set is corrupted and sends an invalid message to SubnetB during the time between originating the validator set update on SubnetA and the time it takes to be accepted on the P-Chain (or for that update to propagate via lightclient to SubnetB as well). In practice, I think this is actually a relatively small failure case, especially if you include a churn assumption.

That being said, as mentioned in the section on Subnet Orchestrated Validator Sets, you can also use the P-Chain lightclient to protect against this case by queuing staking updates on the Subnet and only updating the actual validator set after it has been confirmed on the P-Chain to ensure the validator set doesn't change until the P-Chain has been updated.

We could enforce an even tighter bound potentially including some type of epoch on the P-Chain as well, but I'd lean against this design because I'm not sure the extra security you get against a very particular threat model outweighs the cost of adding epochs or enforcing tighter control here.

[aaronbuchwald]

Definitely open to feedback on the exact threat model that should be used here

[smyyguy]

That being said, as mentioned in the section on Subnet Orchestrated Validator Sets, you can also use the P-Chain lightclient to protect against this case by queuing staking updates on the Subnet and only updating the actual validator set after it has been confirmed on the P-Chain to ensure the validator set doesn't change until the P-Chain has been updated.

Ok, this closes the loop for me, thank you. Enforcing that Subnets update the P-Chain before the staking change actually occurs is what I was missing. Thanks for the clarity here!

[aaronbuchwald]

Sure thing! Again, it depends on the threat model you want to protect against, so it's not strictly necessary, but it's simple enough to make that small change that it seems worth it. Especially if you want it to be robust against a world where there's an auction market for recently expired validator's BLS private keys, which have already received their reward.

[erwindassen]

This indeed goes hand-in-hand with ACP-13 and, in principle, I'm excited to see what this will mean for the subnet ecosystem. As I see it the goal is to make the P-chain more of a communication authentication hub than a chain for managing stake and validator sets. This moves closer to ideas in Cosmos but instead of having a direct chain-2-chain light clients to verify validator set changes here it is chosen to have a dedicated registry in the form of the P-chain. Is this view in any correct?

Furthermore it would be helpful for the discussion (these changes will need validator support!) to clarify the role of AVAX after these changes. To have in writing a mental model would be immensely valuable. Questions that naturally come to mind:

• Will PAYG be enough? (to keep validators incentivized to validate main net that is!)
• Are we envision the utility of AVAX mainly being as fees over the C-chain? (negligible on P and X chains)
• A subnet, under ACP-13 and this proposal, can essentially be run completely independently and chose to use LayerZero instead of AWM (AWM is far superior I know, but LayerZero goes to chains outside the Avalanche ecosystem and is already entrenched). What is there to mitigate a scenario where all subnets are like this with the consequence of AWM essentially being dead and AVAX bound only to the success of the C-chain?

Again, I'm all in for the proliferation of both permissioned and (specially) permissionless subnets and this is a welcome proposal. These questions are to instigate the discussion and clarify areas validators might have doubts.

[aaronbuchwald]

That view is 100% correct. The way I see it is that the core value add of the P-Chain is enabling cross-chain communication and validator set management is probably better off being managed by subnets more directly.

This change along with ACP-13 pushes more in the direction of Cosmos, where the key differences are the cross-chain communication stack and the tech stacks available.

Another nice facet of the P-Chain design is that you could actually create an IBC connection to the P-Chain to facilitate connections to any Subnet on Avalanche in the exact same way.

[aaronbuchwald]

Thanks for raising these economics questions as well, these are tough to answer, but vital and I can only give my 2 cents.

I'd disagree that the fees from the P-Chain will not be enough or self-sustaining. That's the case currently, but the vision is a world with a large number of sovereign networks that have the need for seamless, connect anywhere style communication. Scaling that can significantly increase the amount of fees that the P-Chain collects and the C-Chain fees effectively subsidize it up to that point.

As for the independence of Subnets, I think this is a good thing. I don't think anyone should be artificially locked in to being an Avalanche Subnet when the value from connecting to the network is less than the cost of P-Chain fees.

It's network effects. What is the value of being the first user on Facebook? Literally nothing, there's nobody there. People adopt or try it out because they believe in a vision. These are early adopters.

People adopt because it provides the tech stack that they want and they believe in the vision. In the long term, people are generally rational and will not pay fees if the economic value they get from the interaction comes up short of the cost.

I actually think it's a great signal, when the tech stack provides value even to systems that don't need the interconnectivity. Linux dominates the cloud market. It doesn't charge any direct licensing fees, but it's made orders of magnitude better by the community of developers/users that use it, contribute back to it, and provide support to the broader community. Adoption of the Avalanche tech stack contributes to the Avalanche Ecosystem even where that adoption comes from projects that don't need cross-chain interoperability.

[erwindassen]

Thanks for the reply!

I would love to see the adoption of subnets trigger higher fees on the P-chain. Still, I think we need something of a more concrete analysis or model. Outlining adoption scenarios and such. Taking these changes solely from the technical perspective can be a "foot gun". This is something some reputable research team can try to tackle.

But in regard to your observations about the independence of subnets I couldn't agree more. I am in principle all in for it. It is undeniable that Ava Labs is doing unparalleled work not only in developing the stack, but also the other side of the coin: BD efforts and partnerships. The Avalanche Ecosystem will start reaping the benefits.

[aaronbuchwald]

Good point. I agree it's always better to have data than to not have data. However, I think this may be a scenario where you can't get the data you need to make an accurate projection until you see how people respond to it.

For example, Coca Cola can change their prices in one city to estimate nationwide elasticity of demand before rolling it out a pricing change nationwide. Unfortunately, there's no way for us to make broad changes to the P-Chain, measure its impact on demand, and make a decision after the fact.

So what do you do if you can't measure demand? Well, this is what every startup does. You need some thesis about what value you will provide and design for a world where that thesis proves to be correct. In this case, the thesis is that there's a huge amount of value to be unlocked by enabling the creation of seamlessly interoperable sovereign networks.

The most important question then is not, "how will this change impact demand?" or to develop a model that says exactly how many more subnets are needed to equal the demand generated by a smaller number of subnets locking up 2k AVAX. The most important question is whether this is the right direction to provide the most value. To me, the answer is clearly yes.

[darioush]

In the case that a sovereign subnet wants to continue to use Avalanche consensus, how does the subnet communicate its validator set to the engine?

[aaronbuchwald]

Great question. This would require some refactor to AvalancheGo, so that you can insert your own validator set management into it.

[martineckardt]

Just had an idea how to mitigate the risk of transferring the subnet ownership to a non-existing address (for example by a typo in the contract address or a mistake in calculating the P-Chain address from blockchain ID and contract address):

When a Subnet transfers the validator set management to a smart contract the change only takes effect after an initial message to claim the validator management from that contract has been received.

If an error has been made, the Subnet can just an issue a new transaction transferring the validator set management to the correct address. The claim message is only accepted from the latest address.

[friskyfoxdk]

Really love these ideas and this is a great discussion. Would love to see a solution like this that would allow a more decentralized and automatic management of the validator set for subnets implemented.

[izzetemredemir]

The proposal for subnets to independently manage their validator sets could significantly enhance the Avalanche ecosystem. How will this contribute to decentralization, and what are the potential impacts on security? Additionally, the concept of Subnet Accounts seems promising for improving DevX by offering more intuitive and accessible tools. I believe these innovations could have a positive effect on both the network's performance and user experience.

[aaronbuchwald]

The primary focus of this change is to make Subnets more independent. This change is not directly about improving decentralization, but giving Subnets the ability to experiment more broadly. By opening up the design space, I hope to see more experimentation and innovation.

[sm86]

Re Subnet Orchestrated Validator Sets: I think it might be interesting both: 1. Subnets managing validator set; 2. P-chain managing staking/delegation; The advantage of latter is to enable restaking while former gives more soverignity.
Might be interesting to have easy to use modules for staking/delegation as part of subnet creation tool-kit itself.

Also, important to note that we do validator set reconfigurations at epoch intervals, at end of a day. So, this is not time critical generally.

I think this needs a mechanism to ensure that updates to validator set happens correctly. What if a malicious actor would not want to update the validator set - needs more research here. But overall, I am looking forward to it.

[aaronbuchwald]

Absolutely, see ACP-99 for the first draft proposal to establish a standard.

The logical breakdown in my view is:

• Set a simple to use interface on the P-Chain
• Create a simple SDK to make it easy for VMs to interact with the P-Chain interface
• Integrate those tools into individual VMs, which will need to be on a case by case basis

Making the last part as easy as possible is critical.

[aaronbuchwald]

I agree the timing requirements are not likely to be very demanding here.

There aren't many L1s that require frequent and rapid validator set updates and if the validator set uses epochs, then it would only need to post that update to the P-Chain at the boundary.

[aaronbuchwald]

As for malicious actors, this is why Subnets are controlled by a Warp Derived Address. This provides standard access control over updating the validator sets.

Lmk if you have any more specific questions/concerns about the security model. This work has been continued in #78, which has further spec'd out how this works in practice.