1/ Introducing ๐๐ฎ๐ฅ๐๐ง๐๐ฟ๐ ๐๐ง๐ค๐๐ง๐๐ข๐จ: A Minimal, Performance-Focused, WASM-Based Smart Contract Framework for @avax @AvaxDevelopers
Starting ๐๐๐ฟ๐ผ๐, you can write HyperSDK Programs in #Rust using the ๐ฟ๐๐ซ๐๐ก๐ค๐ฅ๐๐ง ๐๐ง๐๐ซ๐๐๐ฌ ๐๏ธ .github.com/ava-labs/hyperโฆ
2/ First, why "Programs" and not "Smart Contracts"?
This is about "familiarity". When new developers hear "smart contract" for the first time, they have no idea what I'm talking about.
"Programs" convey that if you know how to code, you can do this. That's exactly what we want.
3/ So, how do these newfangled HyperSDK Programs look? Not newfangled ๐.
It is difficult/expensive to reach mass adoption if devs have to learn a new language/use odd dialects of existing languages to deploy their code.
HyperSDK Programs meet devs where they are. It's minimal.
4/ @samlioku and @hexfusion prepared a few examples using Rust to showcase this notion of "familiarity".
8/ Everything HyperSDK is performance-driven and Programs are no exception.
To avoid the biggest bottlenecks devs typically run into when using WASM (memory allocation and serialization), complex objs are never injected into the execution environment (just a reference to them).
9/ The primary "learning curve" for HyperSDK Programs relates to storing/interacting with variables in state.
Normally, interacting with complex objects in Rust (or other languages) is just done "in memory" (ex: a map lives on the heap). Not here.
10/ To interact with complex objects (like a map), developers invoke a "host function" to read specific keys from a map stored in the host environment instead of interacting with the object directly in WASM memory:
11/ Rust not your jam (hint: don't tell a Rust dev that) ?
WASM compilation is supported by many languages. We only have a Rust SDK for now but look forward to community SDKs that unblock development in C/C++/Zig/TinyGo ๐ค .
12/ What can/can't you do ๐๐๐ฟ๐ผ๐? (i.e. What's a "Developer Preview"?)
You **can** write your own HyperSDK Programs and run them in a basic WASM runtime.
You **can't** deploy HyperSDK Programs on-chain (yet).
13/ With any new framework, community feedback early and often is critical for world-class DX.
Although the runtime isn't complete/performant yet, we wanted to shift development into the open as soon as there was a basic foundation to build on.
Let us know what could be better!
14/ Concurrently, we are working on a minimal (strip out all unnecessary WASM functionality), metered, deterministic, Golang WASM runtime to execute these programs based on Wazero ().
15/ Other future work includes (but not limited to):
* Program Constraints (enforce end conditions to protect against bugs)
* Multi-Dimensional Fee Pricing (charge for each resource independently):
* Use State Keys to Create Parallel Execution Treegithub.com/ava-labs/hyperโฆ
16/ Check out my talk at Summit II if you want more context on the HyperSDK and HyperSDK Programs:
17/ Lastly, **HUGE** shoutout to @samlioku and @hexfusion for taking this project from a list of bullets I had on paper into an E2E Developer Preview. โค๏ธ
1/ Unlike other VMs on #Avalanche, HyperVMs now produce blocks continuously (even if empty). #HyperSDKJournal
Why build a block if it doesn't include any state transitions? Although it may sound "wasteful", it has a number of benefits...github.com/ava-labs/hyperโฆ
AWM verification requires fetching the validator set of the P-Chain at the height included in the ProposerVM header of the HyperVM block (computed using reverse diffs).
If there are long periods with no blocks, producers can reference anything between the P-Chain height in the last accepted ProposerVM header and the current P-Chain height.
(It is prohibited to use a height < the P-Chain height in the last accepted header)
1/ Spent the last few days migrating the #Avalanche HyperSDK to use millisecond-denominated block times instead of second-denominated (like all other Avalanche VMs):
Why? So we can remove "block cost" and "surplus fee", of course! โค๏ธ
Block production on Snowman is dynamic (i.e. there is no "slot time" like "every 2s"). Rather, the VM triggers when it wants to build and the consensus engine will ask it to build if it is a preferred producer or no blocks have been produced lately.
3/ I wrote about the unique properties of Snowman/Snowman++ before if you want to dive into this concept: