You: What demo are you working towards to show this off?
Me: You'll be able to mint an asset and transfer it to any other tokenvm-based Subnet. On the way in, you'll specify a tokenvm orders to fill to acquire the destination fee-paying token. HyperSDK can mean HyperSmooth too.
You: Will it be easy for any HyperVM to integrate?
Me: I'm attempting to minimize the integration burden to 1 additional function on the existing Action interface. The HyperSDK should handle everything else for you behind the scenes (should feel like "Warp out-of-the-box").
what can only be described as "god-tier" gif generation
Refactored a BUNCH of the mechanisms I originally implemented to support AWM: github.com/ava-labs/hyper…
As I was adding support to the TokenVM, I realized I was writing a ton of boilerplate code and requiring HyperVMs to know WAY too much about where Warp messages came… twitter.com/i/web/status/1…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Took ~24 hours to implement a new blockchain on top of the #Avalanche HyperSDK that allows anyone to mint, transfer, and trade user-created tokens...all on-chain.
To make the trading UX more accessible, the "TokenVM" includes an in-memory order book to track all open offers on-chain (which it then serves over RPC).
Best of all? It only took a couple hundred lines of code for Actions, Auth, and Storage (other packages are boilerplate).
Core Packages:
Actions: 600 lines of code
Auth: 108 lines of code
Storage: 322 lines of code
The remainder is boilerplate stuff I need to abstract better/wrap in functions so I don't need to re-implement 😅.
To start, I'm just going to allow people to: 1) Create resting orders (with a fixed quantity and price) 2) Interact with resting orders (purchase some/all of the fixed quantity at a set price) 3) Cancel resting orders… twitter.com/i/web/status/1…
This runtime will have a simpler storage model than the IndexVM, so I expect it to be a bit more performant all else equal (no modification to HyperSDK).
1/ This TokenVM all-around should be a simpler starting point than the IndexVM for most devs.
It'll also serve as an embedded integration/e2e/load test within the HyperSDK (so I don't need to trigger the IndexVM CI to test any major changes upstream).
2/ Once the TokenVM is merged, I plan on using it as a testbed to integrate #Avalanche Warp Messaging support into the HyperSDK (which will be my next task after merging this PR).
Banff 9 modifies the VM interface to remove AvalancheGo's dependency on go-plugin (github.com/hashicorp/go-p…) for orchestrating Custom VMs.
If you are running a Custom VM, you must update it to run it with AvalancheGo@v1.9.9.
2/ The removal of go-plugin means AvalancheGo now exclusively manages VM orchestration on the host. This changes nothing for most VM developers, however, it was the last blocker preventing us from adding support for multi-host AvalancheGo configurations:
(otherwise known as the secret project I've been developing over the past 6 months at @avalabsofficial)
1/ First off...why Hyper?
Our SDK development philosophy is **performance above all else**.
If the SDKs we build don't reach hyper-scale (10-100k+ TPS), it won't matter how easy they are to use or how quick you can launch.
Using "Hyper" is a daily reminder of the north star.
2/ We enable anyone to achieve this hyper-scale by employing Avalanche-optimized data structures and algorithms behind a strict but sufficiently generic set of mechanisms (hence the "opinionated") that can be used to implement user-defined functionality.