patrickogrady.xyz Profile picture
Feb 22, 2023 13 tweets 8 min read Read on X
[HyperSDK Build Journal]

Next up: Swaps on the TokenVM

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.

#HyperSDKJournal
Close Order is now complete 👀: github.com/ava-labs/hyper…

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…
Added Fill Order (untested): github.com/ava-labs/hyper…

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).

This is the first Action that uses the conditional fee logic as… twitter.com/i/web/status/1…
Added a cool in-memory order book using the Uint64Heap I wrote for the mempool: github.com/ava-labs/hyper…

This will allow the TokenVM RPC to serve an "Open Orders" endpoint (that we will test in the integration tests).

#HyperSDKJournal
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"!

Now, I just need to add a README and it will be good to merge: github.com/ava-labs/hyper…

Implementing all Actions took 600 lines and implementing Auth only took 108 lines! You can view the… twitter.com/i/web/status/1…
If you want to check out how to mint assets and fill orders, check out the integration tests: github.com/ava-labs/hyper…

(make sure to take a look at how the integration tests make use of the in-memory order book)

#HyperSDKJournal

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with patrickogrady.xyz

patrickogrady.xyz Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @_patrickogrady

Nov 14
Anyone aware of a consensus paper that uses a “loss-y model” for message delivery rather than the typical “eventually delivered” assumption?
The papers I’ve read recently uniformly assume messages will eventually be delivered but never dropped (unlike a real-world setting over a WAN with periodically rebooting nodes) and leave it as an exercise to the reader to craft sound mechanisms to recover from “inevitable gaps”.
While the proofs might be near impossible to write, curious if there isn’t more peer-reviewed work on balancing robustness vs bandwidth/efficiency at different message failure rates or in different recovery scenarios.
Read 8 tweets
Aug 8
I am launching a new company, @commonwarexyz, because I think the communities that will be leaders in the onchain era will take a different path than the ones already paved: specialization.
To accelerate developers that share this perspective, Commonware is building an open, Rust-based blockchain framework architected for excessive throughput, tractable modification, and embedded interoperability.
Today, we are taking the first step towards launching the Commonware Framework. p2p, our first primitive, is now available (in ALPHA) under both Apache-2 and MIT:

docs.rs/commonware-p2p
Read 4 tweets
Jun 25
Is it possible to make a large (> 500 validators) and robust (liveness and safety up to f < n/3 byzantine faults) blockchain snappy (~1s finality)?
1/ Over the last few months, @stephenbuttolph and I explored this question. Image
2/ After many rounds of iteration (i.e. Stephen poking holes in my ideas), we arrived at Vena.

Vena drives finality at network speed, provides strong liveness guarantees, and natively outputs confirmation artifacts (aggregate signature for each block) over large validator sets.
Image
Image
Read 12 tweets
Jun 10
Vena: Optimistically Responsive Consensus Over Large Validator Sets

hackmd.io/@patrickogrady…
1/ Vena is an optimistically responsive consensus protocol in the partially synchronous network model tailored for deployment on public blockchains with large validator sets.
2/ Vena employs a form of "optimistic" aggregation committee broadcast that when successful results in all participants, including the leader, sending less than n messages in a given round.
Read 8 tweets
May 23
1/ 🛠️ 🛠️ #Avalanche Durango 6 is out: 🛠️ 🛠️

This version (v1.11.6) is backwards compatible to v1.11.0. It is optional but recommended for all operators.

🔍 Focus: secp256r1 Staking Keys + Improve C-Chain State Sync Reliability + Fix Connection Tracking github.com/ava-labs/avala…

Image
Image
2/ 🚧 Attn Node Operators: Metrics Refresh 🚧

Durango 6 overhauls the format of many of AvalancheGo's exported metrics. This new format is easier to work with when creating dashboards and cheaper for hosted metrics platforms to ingest.

This work will continue in Durango 7.
Image
Image
3/ ✅ Compatibility Check: VM Interface (v35) ✅

Durango 6 DOES NOT modify the VM interface. If you are running a Custom VM on v1.11.3-v1.11.5 (like Subnet-EVM@v0.6.3), it will work with v1.11.6.

github.com/ava-labs/subne…
Read 8 tweets
Apr 30
1/ 🛠️ 🛠️ #Avalanche Durango 5 is out: 🛠️ 🛠️

This version (v1.11.5) is backwards compatible to v1.11.0. It is optional but strongly recommended for all operators.

🔍 Focus: X/P/C Bootstrapping Optimization + Beta Consolidation + Consensus Engine Fixesgithub.com/ava-labs/avala…
2/ ✅ Compatibility Check: VM Interface (v35) ✅

Durango 5 DOES NOT modify the VM interface. If you are running a Custom VM on v1.11.3-v1.11.4 (like Subnet-EVM@v0.6.3), it will work with v1.11.5.

github.com/ava-labs/subne…
3/ X/P/C Bootstrapping Optimization

Durango 5 now fetches blocks in parallel for the Primary Network using an Interval Tree:

Coupled with an improved peer selection algorithm for fetching, this reduces fetch time by 80%: github.com/ava-labs/avala…
github.com/ava-labs/avala…
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(