When you wish to build your own blockchain for powering your use-case-specific protocols, it shouldn’t be bound by the restriction put forward by the main L1 chain. However, L1 VMs are designed in such a manner that you have to follow a cookie-cutter approach. If you move away from the same, your chain will end up compromising decentralization, interoperability, and security for meeting your project-specific goals.
One might suggest that forking is a good option to overcome this problem, but it has drawbacks, like liquidity fragmentation, because a forked blockchain is a standalone ecosystem.
The need of the hour is to give blockchains the same degree of flexibility like a traditional Web 2 solution without forking and with complete access control over their chains. In addition to this, the process should be simple to construct and integrate. Avalanche Hyper SDK optimizes the data structure and algorithm, allowing developers to customize the VM on their own terms without sacrificing interoperability and fragmenting liquidity.
In this article, we will explore how Avalanche Hyper SDK achieves this through its custom VM-powered L1 subnets.
Avalanche Hyper SDK is the front-runner in the world of blockchain framework to help build high-performance custom runtime virtual machines from scratch without forking the chain or compelling the developer to write lengthy codes. Hence, despite not writing very long chains of commands through codes for their specific VM, the developers own their execution environment, and that’s why Noah Pravecek, the CEO of NodeKit, chose Avalanche HyperSDK for building a fully customized VM for its NodeKit chain.
By the way, if you are looking for NodeKit sequencer integrations, you can easily do them with Zeeve Rollups as a service. Get the details here.
Coming back to HyperSDK. So, through the Avalanche HyperSDK for subnets, the developers can bypass the need to develop everything from scratch using the abstraction to run common run-time complexities that are often challenging when you want to deploy your own VM with full customization, but you do not want to either fork the chain or wait for a longer time for upgrades on the main-chain allowing you to develop your own custom VM, which might take time in eternity to occur.
This simplifies the creation of chains that mirror a common run-time blockchain environment while letting the Dapps define their use cases’ specific rules. So, if a developer is using Avalanche HyperSDK for their subnets that delve into gaming, he/she can redesign their own custom VM performing use-case-specific functions like customizing the gas spent, simplifying user interaction, and increasing the transaction per second as per the changing game environment without having to seek permission from the main L1 chain.
The outcome, if a game or DeFi app, at any instance, experiences a higher network usage, the custom VM-powered L1 Subnet will adjust the environment accordingly without forking or making protocol-level changes that dilute user experience and obstruct mainstream blockchain adoption.
When you are building your own custom chains, you need to think about designing your own VM to manage the run-time complexities as per changing environments. So, you have to crack this enigma code without compromising the transaction throughput because HyperSDK for your custom VM powered L1 subnet means hyper scalability. We are speaking of more than 100,000 to 150,000 TPS to fall within this bandwidth of hyper scalability.
Avalanche HyperSDK abstracts run-time code complexities through the use of Avalanche-optimized data structures and algorithms that shorten the development time of your customized blockchains from months to days. So, you just need to write maybe 500-1000 lines of code to make the VM customized as per your application-specific need. Avalanche HyperSDK makes this possible for your subnets by abstracting everything that you can think of while creating your VM for your subnet in the following manner;
Triggering a Partial Transaction Execution
In the partial transaction execution, the subnets created using Avalanche HyperSDK will trigger an action that will request a result from an execution. In this pursuit, any arbitrary execution/function will be requested. If the execution is successful, HyperSDK Smart-Contract Based RunTime execution will be triggered, an optimized fee will be deducted, and state change will occur. However, the data will be stored as blob-data and subsequently destroyed through an x/merkledb, a path-based merkelized Radix tree implementation, which significantly reduces the on-disk footprint of any HyperVM by deleting the data that is no longer needed.
So, a minimal fee will be deducted by exiting the execution if only a few conditions are met. The trade-off of this practice will help meet hyper scalability because all the transactions will be executed in the custom VM environment, and they will pass upon meeting a threshold limit. If a weighted average of the conditions are met, the transaction passes. If not, they are rolled back, and the user pays either a bare minimum fee or no fee, as per the protocol rules.
Furthermore, Avalanche HyperSDK doesn’t store or index the transaction like other blockchains in archival mode, which saves storage costs. On the other hand, Avalanche HyperSDK for subnets will store the transaction in HyperVM in SQL database or Kafka Stream. Whenever a query is created, the HyperSDK will trigger the HyperVM to validate the data by relaying the information from the SQL and Kafka database servers. If the transactions are executed and finalized, the relative data will be deleted from the server via an x/merkledb, as mentioned above.
Using Account Abstraction for Authorization
Instead of validating every single transaction through an AUTH Module, the Hyper VM provides all the registries of supported AUTH to the Avalanche Hyper SDK, which simultaneously validates the transactions as they occur. It is made possible through a Dynamic State Sync model, which allows any node joining the Hyperchain to validate only the most recent state instead of all the transactions on the subnet. Because, if all the transcations on the subnet have to be downloaded by the new node joining the Hyperchain, it will slow down their operation.
On the contrary, the HyperSDK uses X/sync, which is a bandwidth-aware dynamic sync implementation powered by Avalanchego that verifies AUTH Modules from simplified signature verification to WASM Blobs and destroys the same after the process is complete to free up the chain and keep only the necessary data in it to build and verify the next block. .
Using Nonce-less Transaction
While most blockchains use Nonce to counter double spend errors, Avalanche HyperSDK uses a Time History. So, if a specific time has passed, such transactions are not included in the block and it can significantly improve the mempool performance because multiple transactions from a single account need not have to be stored in the mempool .
This makes the execution network faster because a node can gossip any valid transaction to any node instead of the transaction that was specifically executed at that very moment. In this way, it completely revolutionizes the lag time on the mempool and possibly averts the MEV scams as well.
Quick communication for faster Updates
Unlike in other VMs, where all the state transitions or protocol upgrades are broadcasted to the participating validating nodes and they provide an approval for the same, which delays operation, Avalanche HyperSDK makes sure that every object that appear on-chain on HyperSDK Custom VM like actions/ AUTH and Unit Price are time stamped and simultaneously broadcasted at one point of time across the network so that everyone can at a time participate, accept or deny the changes in any form: be it a fee modification or an authorizing action restricted based on consensus.
Smart Gossip
While other VMs gossip the transaction to all the validators, the Avalanche Hyper SDK Custom VM Powered L1 Subnets gossips the transcations to only a few of the upcoming block prospers through the use of SNOWMAN++ ‘s LookAhead Logic which uses a SOFT Proposer Logic selecting a single proposer to validate the block but the block propagation is open to all for challenge. This is very effective in reducing the lag in the gossip when multiple proposers have to participate and vote for a change or inclusion of the transcations in the block. In this way, it significantly improves the transaction speed.
Moreover, there’s a choice given under Avalanche Hyper SDK Custom VM Powered L1 Subnets blockchains where proposers can choose to either accept blocks from RPC instead of a node to node gossip. It entirely depends on what type of finality you wish to keep for your faster blockchain to support your use-cases specific subnet hosted on top of the Avalanche HyperSDK.
Parallel Transaction Execution
While in other VMs, your chain deployed on top of it will have to abide by the rules of the chain while executing the transaction. For example, they will have to validate the transcations occurring in sequence, the Hyper SDK custom VM chain uses executor package which provides an executioner key to the validators that they can trigger to authenticate and execute all non-conflicting transcations. For this, the Hyper SDK uses HyperVMs AUTH and Action executionary codes which are prespecified and they execute in nano-seconds.
For this purpose, cross-subnet WARP messaging is used, which not only expedites cross-subnet communication but also eliminates the need to have bridges for interoperability among the greater subnet ecosystem. In this way, allowing your application to create a custom VM for its state execution and participation with the greater Avalanche ecosystem.
Projects built on top of blockchains are facing an innate technological barrier where they need to abide by the specifics rules of the L1 chain hosting their application. In this way, instead of focussing on improving their project. For example, a DEX should be more concerned at improving the features on their protocol. However, they are fixated at improving the speed and scalability and they give very little time to improving their ecosystem from a feature’s standpoint.
After the introduction of the custom VM powered L1 subnets provided by Avalanche Hyper SDK, the application can shift their focus from concentrating at complying with the execution environment to improving the UX on their protocol. While the HyperSDK will help them launch as a HyperChain subnet and scale their ecosystem as per the changing trends without having to make many adjustments on their protocol.
Developing your application and hosting the same on top of blockchain for trust, transparency and cost effectiveness shouldn’t end up like a complex task for businesses. Avalanche Hyper SDK is making the development process simple by abstracting the complex runtime coding. In this way, any developer can look forward to customizing their subnets and innovating the same to support their use-cases as per the changing situation without getting pinned by technicalities of deploying on top of the blockchain.
Avalanche HyperSDK for custom VM powered L1 subnets allow any type of use-cases from gaming, NFT marketplaces to DeFi to be hosted on top of the Avalanche ecosystem as a subnet without compromising the speed, throughput features and others. Hence, the ecosystem can become much more diverse and sustainable for improving the future of the blockchains.
Zeeve’s appchain infrastructure as a service, let anyone create their custom Avalanche Subnets with plug-and-play developer tools and fully managed infrastructure. Zeeve also provides an Avalanche Management Dashboard for effective management of Avalanche Subnets. And the good news is, this can be utilized for both Zeeve hosted and self-hosted nodes. The complete list of features for the management dashboard is added above.
The cherry on top is you can view and manage your Subnet network from your Android and iOS devices on the go.
If you are already running on a blockchain infrastructure and want to migrate to Subnet, our expert team can help you do that without experiencing any downtime or data loss.
For more information on Zeeve managed Avalanche Subnets, visit our webpage. If you have any further queries, schedule a call with our Avalanche Subnet experts and see how we can simplify your Subnet experience.
