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"!
Today, we’re announcing Route 66 (a new initiative co-led by @coinbase to make it faster and cheaper to connect to specialized blockchains) and a strategic investment from @cbventures.
To better compete with today's web, onchain products are blurring the line between blockchain and application.
Whether stablecoins with dedicated blockspace, tighter spreads with encrypted mempools, or games with fair randomness, blockchains are modded more than ever.
With @tempo, what you can see is just as impressive as what you don't.
In each round of consensus, Tempo validators emit a set of BLS12-381 threshold signatures that can be verified against a static network key (maintained across validator set changes) 🔐
The first of these signatures provides an embedded VRF.
It powers just-in-time leader election (no one knows who the next leader will be until the previous round is notarized/nullified) and provides onchain randomness (for blind auctions backed by Timelock Encryption).
The second of these signatures is over the block (attesting to its finalization in ~48B).
This "certificate" can be used by users to verify the validity of chain data provided by RPCs and to drive interop with other chains (just verify a proof against the static network key).
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.