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…
At @luigidemeo's suggestion, going to start tagging these with #HyperSDKJournal to make them more searchable. 🙏
Finding that I'm frequently in need of a unique ID to name things that my Actions create (like an OrderID).
There isn't a great way to do this with the current interface because Actions need to provide all StateKeys they'll touch before execution. This means we can't just use… twitter.com/i/web/status/1…
This change looks like:
Create Order is done...now working on Close Order.
Then, I'll add support for actually filling one of these resting orders.
After all that, I'll add a number of fun integration tests that should make it clear how to interact with the TokenVM.
You can see that most of the work of adding an Action to an existing HyperVM is to: 1) Define the on-chain representation 2) Add any missing "Storage" functions (in this case, I needed to add the ability to read orders from… twitter.com/i/web/status/1…
To make the output of a fill more useful, I also added a custom result marshaller that contains the result (how much you got vs how much you expected to get).
We now update the in-memory order book whenever a block is accepted 🚀
Next up: testing + RPC support
Went down the numerical precision rabbit hole for WAY too long working on overfill refunds (if you attempt to purchase more than the remaining units left on a order).
It is critical to support this flow as someone else may trade at the same time as you (so the order you thought… twitter.com/i/web/status/1…
After making this change, I was able to finish all the code and tests for the "TokenVM"!
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 😅.
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.
Banff 8 does not modify the VM interface. If you are running a Custom VM, you don't need to update it to run it with AvalancheGo@v1.9.8 if you are already running AvalancheGo@v1.9.7.
This version (v1.9.7) is backwards compatible to v1.9.0. It is optional but recommended.
🔍 Release Focus: Dynamic State Syncing Support + Improved Chit Handling + NAT-PMP Fixes
1/ 🚧 VM Interface Update (v21 -> v22) 🚧
To support Dynamic State Syncing, we had to make some small tweaks to the VM interface. If you are running a Custom VM, you'll need to update to VM@v22.