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"!
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.
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:
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.
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.
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.
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.
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.