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 😅.
Next up: Adding #Avalanche Warp Messaging so you can bridge your user-created assets to other TokenVMs on different Subnets.
Quick Detour....
Decided to do a quick pass on increasing token functionality before migrating my energy to AWM: github.com/ava-labs/hyper…
This will add support for minting from the same token multiple times (instead of just during creation), adding mutating metadata (to support… twitter.com/i/web/status/1…
Just added a bunch of new token functionality. I now think this is enough to merge the TokenVM MVP.
Another takeaway after working on this improved token functionality is that I find it much easier to add complex functionality than a traditional smart contract (mostly because I just get to write directly in Golang and use all its tooling out-of-the-box):
Turns out I accidentally implemented a sandwich-resistant trading mechanism in the TokenVM by requiring orders to be explicitly specified when filling (needed for populating a transaction's "StateKeys")...
The obvious downside of this design is that transactions that seek to fill contentious orders (good deals) will probably have non-trivial revert rates.
Will have to keep an eye on that and see if it gets out-of-hand (probably a function of average order size)...
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.
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.