Subnet Rebranding #45
Replies: 6 comments
-
|
I'll respond to a few of the points: In terms of the marketing of "subnets" imo this would be a discussion about whether it's better to have everyone who comes across the term "subnet" and what it implies want to do it, or if it's about marketing to find the teams who are understanding the image it's describing - that you'll have a "subnet" which can have more than one blockchain. Agreed you'll probably get more people interested if you just talk of it as a "blockchain" building framework like the Cosmos SDK. I like ACP13(with the locking requirement) because it gives the subnet some economic security in its earliest stages. I think until the subnet can prove it can cover the cost of security(in whatever form economic, cryptographic, or a combination of the two) this is sort of required. Kind of a walk before you run, run before you fly kind of deal. |
Beta Was this translation helpful? Give feedback.
-
I wrote a bit about what can/can't be enforced on Subnets (the Primary Network doesn't know anything about what is going on in them) when responding to ACP-13 questions: https://hackmd.io/@patrickogrady/100k-subnets#Can-you-create-Subnets-for-free-if-they-use-AVAX I'm not sure how you would enforce that any Subnet pays some % of fees to the Foundation? Seems like you'd either need to prove state transitions to the Primary Network (not scalable) or have the Subnet emit some data via Warp (easy to game if all the validators on the Subnet want to cheat). Did you have another approach in mind? Even if you did prove something to the Primary Network (maybe in a SNARK/STARK), I don't think there is a way to prove that your proof actually corresponded to the chain you are running on "Snowman Consensus". I'm not aware of any live blockchain that pays fees back to a parent chain (outside of Polkadot which handles validation of all parachains). |
Beta Was this translation helpful? Give feedback.
-
|
To avoid confusion, Once a PR is opened to officially propose an ACP, a number is assigned: https://github.com/avalanche-foundation/ACPs#step-2-propose-an-acp-via-pull-request |
Beta Was this translation helpful? Give feedback.
-
|
I concur. Please rebrand subnets to something else!
|
Beta Was this translation helpful? Give feedback.
-
|
The rebranding of subnets in the Avalanche network, as proposed by @rushimanche, may undermine the established brand value and identity that subnets have within Avalanche. These subnets are integral to Avalanche's unique position in the blockchain space. Changing this familiar aspect could confuse users and weaken Avalanche's brand recognition. Thus, it's crucial to retain the current structure and identity of subnets in the Avalanche ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
For some time wanted to add support for @rushimanche's suggestion: @iwillpat and @luigidemeo among others have advanced the idea of Avalanche as an L0. I think this fits with what Rushi is proposing here. It's a brand and architectural idea that gives big space for projects to occupy -- being connected via the p-chain and not subordinate to any. (Also, separate from the reference term for teams and developers, businesses are going to need a nomenclature for use in the daily course of business to refer to the blockchain territory of their firm.) |
Beta Was this translation helpful? Give feedback.
-
Abstract
This ACP proposes significant changes to the Avalanche network, particularly in how subnets are positioned and utilized. The term 'subnet' is perceived as limiting, suggesting that technology built on it cannot surpass the C-Chain. This proposal recommends rebranding and repositioning subnets to highlight the flexibility and power of Snowman consensus. It suggests eliminating the AVAX requirement for running subnets to lower the entry barrier for builders and suggests that a portion of transaction fees on chains using the Snowman consensus be directed to the Avalanche Foundation. The overarching aim is to streamline the ecosystem, making it more accessible and appealing to a wider range of developers and investors.
Motivation
The term subnets is decently harmful for teams looking to innovate within the tech stack. The word itself implies that any technology provider using a "subnet" will never be able to outgrow the C-Chain. Especially in times of token price volatility and network inactivity, this creates a ceiling for teams in the eyes of teams not familiar with the ecosystem, especially investors both in private and public markets. The Cosmos ecosystem did a phenomenal job with positioning here as teams did not have to be tied to the price action of $ATOM to garner community - Akash, Osmosis, Berachain, Sommelier, DYDX are all great examples of teams that are able to leverage an existing framework while maintaining sovereignty over their brand image.
The AVAX requirement to run a subnet stifles innovation. If I am a builder without significant backing, I will never be able to afford the tens of thousands of dollars it takes to run a mainnet node. I will simply turn to a rollup provider who will oftentimes pay me large amounts of money / invest in my round to run a rollup that is virtually free.
The problem is very clear with the subnet thesis: it is too expensive to run a subnet and speculators are generally bearish on the term subnet especially when C-Chain activity is not optimal (which in turn makes it difficult to raise capital to pay the costs for the subnet).
Specification
Required Changes
Avalanche is still home to the best consensus on the market: Snowman. The only thing that the Foundation and the ecosystem should care about is the Snowman Consensus - the rest are cool features that people can use once Snowman is adopted on a mass scale. I propose a few major changes.
Technology positioning: Separate subnets from Snowman/Avalanche SDK/Avalanche Stack. Subnets are great for institutional players and newcomers to the blockchain industry as it simplifies the explanation of blockchains. Launching your own subnet means launching your own blockchain for your game/bank/institutional use case. For the general Web3 public, there should be an independent category to leverage Avalanche’s technology without even referencing it (which is the ultimate goal for any infrastructure).
Market heavily the Snowman Consensus and different ways to use it. The average developer / speculator currently does not know about Snowman and its benefits. In reality, Snowman is a lightweight and quick consensus model that can be used for various use cases (shared sequencing, Layer 1 consensus, parallelized order books, trustless bridging). When a team comes to Avalanche and when Avalanche markets them, they should not be referred to as subnets; instead, say; rather say it is a team using the Avalanche SDK (I would even rebrand it away from Avalanche or anything Snow related to further distinguish the technologies. Tendermint != Cosmos/ATOM). The word subnet needs to be taken behind the barn and shot for the Avalanche community to scale.
Promote public good development that is separate from the Foundation's interests: At the moment, I am only aware of two teams building Avalanche infrastructure full-time (GoGoPool and Ash). Developer interest peaks when developers are able to build new infrastructure that enables new use cases. For example, there are several teams building zk-IBC to bring IBC (a native Cosmos idea) to other ecosystems like Ethereum. These teams have been able to successfully raise capital, bootstrap communities, and align with the interests of other ecosystems. This in turn validates the Cosmos thesis and brings mindshare to the technology. I have not seen this happen yet with Avalanche.
Be willing to adjust to market interests: Solana/Toly does a great job of this. The Solana community will double down on the need for monolithic high-throughput chains but at the same time be willing to support opposing viewpoints especially seen during the modular period we are in now. Despite the fact that Ethereum and L2s go starkly against Solana's core value propositions, Solana's leadership and community supports initiatives like Eclipse, speaks at conferences with other communities, aligns influencers from all parties, and most importantly keeps the discussion constantly open. Snowman should be promoted within the modular thesis as part of the modular stack that can also be used to scale Ethereum and other ecosystems. A great example is shared sequencing where validators part of the Snowman consensus mechanism can sequence transactions for Ethereum settlement. I would even use resources for the Avalanche Summit to bring minds from Solana, Ethereum, Cosmos, etc. Maybe even rebrand from the Avalanche Summit / have separate side events dedicated to modularity, VMs, or whatever technology can best use Snowman.
Scrap the AVAX requirement for subnets. The reason why Cosmos Zones (rarely ever referenced to as Zones just Layer Ones) are so successful and have a vibrant builder community is because ATOM is not heavily involved; rather, it is used as a strategic asset for protocols to leverage if they so choose to. Avalanche ought to do the same. A model I like is where a small percent of the fees generated by a chain using the Snowman consensus goes to the Avalanche Foundation (For example, 1% of transactions in MVMT are swapped to AVAX). This lowers the barrier to entry for builders while providing sustainable revenue to the Foundation.
Market heavily AWM. Avalanche Warp Messaging might be one of the greatest innovations in trust-minimized bridging and liquidity access in blockchain. There should be an ardent focus on developing content and use cases for AWM. More importantly, it should not be called Avalanche Warp Messaging. Teleporter is a good name but it is important to strike partnerships for maintenance and development with other teams. The main goal is to get Teleporter/AWM in the hands of Ethereum, Cosmos, and other ecosystems so teams can recognize the power of it. I would even suggest a team to spin it out of the foundation and do business development for it as a third party. If AWM remains within Avalanche, it will never scale to the levels of IBC and Axelar (these also started as Cosmos-focused protocols).
While I have many more insights to share, I'll draw my remarks to a close with a set of key recommendations, intended to refine the Avalanche ecosystem and streamline its ongoing evolution:
By proactively addressing these concerns and leveraging the inherent strengths of the Avalanche technology, there's immense potential to see it flourish, even beyond its current ecosystem.
Open Questions
Beta Was this translation helpful? Give feedback.
All reactions