Banff: Elastic Subnets
Banff will activate on the Fuji Testnet at 10 a.m. EST (2 p.m. UTC) on Monday, October 3rd. The Avalanche Mainnet activation time will be announced in the coming days.
The pre-release code for the Banff upgrade is now available. The upgrade will activate at 10 a.m. EST (2 p.m. UTC) on Monday, October 3rd on the Fuji Testnet. Note, this pre-release code only works on Fuji. If you run it on Mainnet, it will exit on startup.
Pending a successful Banff activation on Fuji, the Avalanche Mainnet Banff activation time will be set and a Banff-compatible AvalancheGo release (v1.9.0) for Mainnet will be published.
This upgrade includes protocol-level changes that are not compatible with AvalancheGo versions < v1.9.0. If you run a node on Fuji Testnet, it is recommended that you update your software to AvalancheGo >= v1.9.0 before the activation time on Fuji. If you are a Mainnet node operator, there is no action required until the official AvalancheGo@v1.9.0 code is published.
Elastic Subnets
Banff unlocks the ability for Subnet creators to activate Proof-of-Stake validation and uptime-based rewards using their own token on their own Subnet. This means that for the first time anyone can become a validator of a Subnet by simply staking its token on the P-Chain. Subnets that choose to enable these new features must undergo a one-time transformation into a new type of Subnet called an Elastic Subnet.
When enabling Elastic Validation, the creator permanently locks the Subnet from future modification (they relinquish their control keys), specifies an Avalanche Native Token (ANT) that validators must use for staking and that will be distributed as staking rewards, and provides a set of parameters that govern how the Subnet’s staking mechanics will work (i.e. “what is the min stake amount”). Some of these configurable parameters are listed below:
- Asset ID (asset used for staking and rewards)
- Initial Token Supply (asset current supply after transformation)
- Maximum Supply (amount of asset that will exist after all rewards minted)
- Min Validator Stake (minimum amount of funds required to become a validator)
- Max Validator Stake (maximum amount of funds a single validator can be allocated, including delegated funds)
- Min Stake Duration (minimum number of seconds a staker can stake for)
- Max Stake Duration (maximum number of seconds a staker can stake for)
- Min Delegation Fee (minimum percentage a validator must charge a delegator for delegating)
- Min Delegator Stake (minimum amount of funds required to become a delegator)
- Max Validator Weight Factor (factor which calculates the maximum amount of delegation a validator can receive)
- Uptime Requirement (minimum percentage a validator must be online and responsive to receive a reward)
Enabling Elastic Validation on a Subnet is entirely optional and at the discretion of the creator(s). Those who prefer to have more control over a Subnet’s validator set will always have the option of retaining the default configuration of a new Subnet, which calls for specific nodes to be designated as validators by the creator.
At Banff activation, it will only be possible to use Avalanche Native Tokens from the X-Chain as stakeable tokens on Elastic Subnets. In a future release, support will be added for using ERC-20s as ANTs (which can be used as stakeable and rewardable assets on Elastic Subnets).
Early Subnet Validator Removal
Subnet creators must specify an explicit staking duration and stake weight for each validator they add to their Subnet’s validator set (unless the Subnet has already been transformed into an Elastic Subnet, in which case validators determine this when staking). Once set, a validator’s staking duration nor their stake weight can be modified.
While this isn’t a problem the vast majority of the time, a Subnet creator that adds a validator with the wrong stake weight or that is underperforming won’t be able to remove the troublesome validation until the predetermined staking duration concludes. Until now!
In Banff, Subnet creators gain the ability to remove a validator before the conclusion of its staking period from a Subnet. If a Subnet has already been made Elastic, a Subnet creator can also use this transaction to remove validators that were added before token-based staking was enabled.
P2P Protobuf Messaging
In all previous versions of AvalancheGo, all peer-to-peer (p2p) messages sent between nodes used a custom serializer to encode/decode structured data (see message/codec and wrappers). This implementation is highly optimized for AvalancheGo but is difficult to extend without invalidating existing messages/data because it isn’t backwards and forwards compatible. While this library is great for encoding data that requires a canonical format (e.g. blocks), it makes modifying AvalancheGo networking packages unnecessarily cumbersome.
In Banff, all p2p messages are serialized using Protocol Buffers (Protobuf). While there are hundreds of serialization approaches, Protobuf was the obvious choice for this enhancement because it is already used widely throughout AvalancheGo by the Custom VM handler. Outside of the wire format being backwards and forwards compatible, our new Protobuf-based serialization package uses less memory, uses less bandwidth, and is faster than our previous implementation. Not to mention, serialization code for other languages can be automatically generated. You can view all *.proto files used by AvalancheGo here.
Custom Delegation Fee Recipients
When designing Elastic Subnets, we created a new type of staking transaction to unify all token-based staking interactions (whether on the Primary Network or an Elastic Subnet). This new transaction type enables validators to specify a separate reward recipient for delegation fees, in addition to adding support for staking ANTs
This fee payment flexibility allows staking providers to directly compensate their partners for attracting delegations to their validators. As you might be guessing, this feature works equally well on the Primary Network and on Elastic Subnets.
FAQ
How do I upgrade my node?
The process to upgrade to AvalancheGo v1.9.0 is the same as any other upgrade. If you build from source, run the build script as before. If you use the pre-compiled binaries, invoke them as before. If you use the installer script, use that as before.
Once you start AvalancheGo v1.9.0, you do not need to do anything else. More information on updating a node can be found here. As a reminder, it is best practice to have a backup of your staking key/certificate.
Do I have to upgrade my node?
If you don’t upgrade your validator to v1.9.0 before the Avalanche Mainnet activation date (which will be shared in coming days), your node will be marked as offline and other nodes will report your node as having lower uptime, which may jeopardize your staking rewards.
Is there any change in hardware requirements?
No.
Will updating decrease my validator’s uptime?
No. As a reminder, you can check your validator’s estimated uptime using the `info.uptime` API call:
I think something is wrong. What should I do?
First, make sure that you’ve read the documentation thoroughly and checked the FAQs. If you don’t see an answer to your question, go to our Discord server and search for your question. If it has not already been asked, please post it in the appropriate channel.
About Avalanche
Avalanche is the fastest smart contracts platform in the blockchain industry, as measured by time-to-finality, and has the most validators securing its activity of any proof-of-stake protocol. Avalanche is blazingly fast, low cost, and green. Any smart contract-enabled application can outperform its competition by deploying on Avalanche. Don’t believe it? Try Avalanche today.
Website | Whitepapers | Twitter | Discord | GitHub | Documentation | Telegram | Facebook | LinkedIn | Reddit | YouTube
Banff: Elastic Subnets was originally published in Avalanche on Medium, where people are continuing the conversation by highlighting and responding to this story.
