
Rust dev. Proud contributor to #Kaspa.
Dubai, UAE
Joined July 2023
- Tweets240
- Following67
- Followers1.8K
- Likes929
I finally wrote a book that covers vprogs, and in particular tic-tac-toe implemented as a vprog on testnet-10. It follows the game down to the machinery underneath, with diagrams and appendices for the details. Welcome to explore it and ask questions: biryukovmaxim.github.io/vpro…
Maksim Biriukov retweeted
Tic-tac-toe is not the big deal. What happens underneath it is.
A working vprog on Kaspa testnet, built by @Max143672, runs the game off-chain, proves every move followed the rules, and keeps the funds locked until Kaspa verifies that proof.
We explain how it works, why it matters, what makes the Kaspa approach different and what developers can already try. $KAS
kaspa.news/articles/small-ga…
Tic-tac-toe is live on Kaspa testnet: the first vprog, a verifiable program with real execution and real settlement, running since yesterday.
You can play it here: vprogs-tt.izio.fr/
(Requires private key and some testnet funds)
We still need to review and merge a stack of PRs, however this is already a working POC. UI/UX was never a priority; the frontend can be enhanced or built separately
I'm gonna work on mdBook covering the parts of the system I consider meaningful and a workshop on vprogs and building apps on top
For Devs: this is the invitation. Play the game, read the code, build your own vprog.
Game code: github.com/biryukovmaxim/vpr…
vprogs framework: github.com/kaspanet/vprogs/t…
Hey guys,
It's been a while since my last post, and I feel almost bad for not posting anything for such a long time 🙈
Unfortunately, I caught a really nasty infection on my way home from the KAS meetup and have been stuck in bed with a high fever and brain fog for the last few weeks.
I'm still not completely back to normal, but since I'm finally starting to have a bit more energy, I wanted to use the opportunity to share some thoughts about the meetup, because I think it will turn out to have been extremely influential for the future of Kaspa.
For anybody who doesn't know what I'm talking about: about 3.5 weeks ago, KAS organized an internal meetup between core contributors (and some additional community developers) at an undisclosed location in Europe.
When I first learned about the plans for this meetup, I didn't really know what to expect.
I've been to developer meetups before, but those were traditionally very narrow and task-focused. E.g. you got a team together to work on a specific problem that was difficult enough to deserve the shared attention of everyone involved.
In the case of Kaspa, however, we have relatively small and independent teams working on a number of different topics in parallel, such as vprogs, covenants, SilverScript, Argent, etc.
There are, of course, interfaces between these topics, but they all have their own independent designs and problem spaces.
This independence of developers is one of Kaspa's biggest strengths, but it also creates a situation where not everybody is always fully up to speed with what is happening elsewhere in the project.
For me personally, this is probably the biggest obstacle to becoming an effective communicator.
To feel confident discussing things publicly, I need to develop a deeper understanding and intuition for the subject. And that requires knowing not only the final design or code, but also the roads that weren't taken and the mountains that had to be climbed along the way.
What Kaspa really needed, wasn't a narrow, task-focused meetup, but a broad, vision-building one: something that connected the dots and allowed the different teams to develop a deeper understanding of each other's work, and ultimately see how all of it fits together as a coherent whole.
And the reason I'm telling you all of this is that this is exactly what the meetup turned into.
A week of open sessions and discussions covering the different development efforts, giving everyone the opportunity to build that deeper shared understanding.
I think it was a huge success!
I'll write a little more over the coming days about specific topics like Argent (which I really like), but I also have quite a lot to catch up on after being sick for so long.
@Max143672 did a really good job working through a lot of the open tasks around vprogs, and I now have a lot of code to review :'P
1) vprogs provides a general-purpose programming framework, allowing developers to implement arbitrary program logic rather than being limited to the subset supported by native scripts.
2) In the UTXO model, an object can only be consumed once, making highly shared resources (like DEX pool) difficult, every transaction competes for the same UTXO.
In contrast vprogs introduces managed shared objects, where many transactions can target the same logical object concurrently while the framework deterministically serializes access
3) Native scripts impose limits on execution complexity. Developers has to decompose what is conceptually a single operation into multiple scripts and intermediate states.
often it requires introducing additional transactions, the sole purpose is to advance the application state machines.
vprogs allows these workflows to be implemented as one coherent program, reducing protocol complexity, latency, transaction overhead, and the amount of application-specific state management.
4) Existing algorithms and applications from other ecosystems can be ported with minimal conceptual changes
All of these also reflect devex
Replying to @KASPAglobal
What will vProgs add over toccata? Given that they've recent found that atomic composability is possible right now
Maksim Biriukov retweeted
Replying to @Max143672 @KASPAglobal
There’s an internal devnet that’s been running since Feb also. Work is ongoing to:
- implement incremental UMC (context: paper version is not efficient enough for mainnet, so an incremental version is necessary for production usage)
- onboard devs from core to get more people up to speed on dk
As optimization/privacy relaxation you can use the message to establish 1-1 session, webrtc based for example. In most cases people should be fine to share their IP with the person they wanna talk to. The same way voice chat may be established.
Anyone wanna build that?
Replying to @ascaris_lumb
1 $KAS gets you about 500 messages. The fee does not go to us it goes to miners. Using Kaspa for chatting is to give you guarantees that centralized chat platforms don't give you like privacy and no data collection. People pay for social platforms all the time its not weird. People pay almost $100 a year just to get a check mark on their name on X.
tn10.kaspa.stream/transactio…
U know what is that? first post-quantum signature on kaspa just landed. XMSS^MT
The script is huge (~84KB) because it has to unroll a loop of ~1,650 hashings on-chain but it verifies. and it works.
isn't that cool?
toccata to everyone
2/ but raw XMSS is fragile: it's stateful, and reusing a one-time key is fatal.
so who enforces "never reuse"?
kaspa does. KIP-20 covenant IDs (github.com/kaspanet/kips/…)
The design splits the wallet into two scripts:
RECEIVER accepts unlimited payments, fully in parallel its only spend path: the spender must be spent in the same tx and the receiver pins which spender by its covenant ID - that's what binds the two together
SPENDER embeds the XMSS root + a counter. every spend advances the counter, so no leaf can ever be signed twice. So reuse becomes impossible by consensus
Maksim Biriukov retweeted
Thrilled to host @asaefstroem, a protocol developer and ZK engineer, author of KIP-16, ZK verification opcodes in Kaspa L1.
He will deliver a talk "A Path Down Covenant Road: What Covenants & ZK Unlock on Post-Toccata Kaspa" at our Kaspa x Igra day, June 19 at Berlin Blockchain Week.
Register here: luma.com/q8zh39zs
Toccata is arguably one of the biggest and most anticipated upgrades $KAS has shipped. Covenants + ZK opcodes change what you can build on it.
I’m speaking at this Berlin Blockchain Week workshop, breaking down how they actually work and where the sharp edges are.
What do you most want covered? 👇
Maksim Biriukov retweeted
**Official Toccata Release — Mainnet Hardfork Activation Included** (Links in reply)
We’re excited to announce the official Kaspa release containing the **Toccata Hardfork** activation logic.
Toccata is scheduled to activate on mainnet at DAA score `474,165,565`, expected around **June 30, 2026, 16:15 UTC**.
This is a consensus-changing upgrade. All node operators, miners, pools, exchanges, indexers, wallets, and infrastructure providers must upgrade before activation to remain compatible with the network.
Toccata introduces a major expansion of Kaspa L1 capabilities, including:
• **Native L1 covenant support** through transaction introspection, allowing for more expressive contracts, including stateful contracts
• **Covenant IDs**, providing stable covenant lineage across UTXO transitions, so covenant instances can preserve continuity as their state moves from one UTXO to the next
• **ZK proof verification on L1** via `OpZkPrecompile`, enabling to trustlessly offload computation off-chain.
• **Partitioned sequencing commitments**, improving support for based ZK applications by making lane-local proving scale with relevant activity rather than global throughput
Please upgrade as soon as possible and verify your nodes are running the new release well before the activation DAA score.
Thank you to everyone who contributed to designing, implementing, reviewing, and testing Toccata.
After the latest merge I'm now top-3 contributor on every metric 😎
Maksim Biriukov retweeted
I think one day we will look back and better understand, myself included, how important this component is for Kaspa and for the sequencing and programmable capabilities it opens up. More on that in followup posts when I get some air. A few days late, but this is the nearly final step before the Toccata feature freeze and TN12 reset.
Huge kudos to @Max143672 for shipping such a monumental end-to-end change with elegance.
Approved and merged: github.com/kaspanet/rusty-ka…
Also, on a personal note: ai was incredibly powerful in this review journey. Not as a substitute for judgment or ownership, but as a force multiplier for understanding, walkthroughs, invariant checking, ascii drawing, and staying deep in a very large design. And yes, that includes writing this paragraph ;)
The movie you must watch
replay of yesterday spontaneous "webinar" that happens on Discord, in case you couldn't follow it and still want to
youtube.com/watch?v=9t-14LJy…
replay of yesterday spontaneous "webinar" that happens on Discord, in case you couldn't follow it and still want to
youtube.com/watch?v=9t-14LJy…
Maksim Biriukov retweeted
muhex v0.5.1 released!
This is a minor one, but we improved the way we handle unaligned inputs, so the performance doesn't tank as hard.
We now have a much better (and more honest) benchmark results page. We're still the fastest overall, and by far in many cases.
DONE.
Just completed an initial working implementation of a based zk covenant/rollup with KAS canonical bridging (over TN12 capabilities).
This work is part of the covenants++ hardfork milestone roadmap(gist.github.com/michaelsutto…)
The work is scoped as PoC however all significant challenges related to canonical bridging have been thoroughly addressed and the implementation is already mature. The vm itself is a simplified account model supporting only 3 actions: entry/transfer/exit.
Notable changes and improvements over the described research spec:
- Uses the new covenant ids scheme for unforgeability
- Uses an additional covenant script for succinct claim-based outbox/exit ops
- Implements a clever shortcut between entry and exit ops without going through the state transition singleton UTXO for streamlined UTXO management
Branch: github.com/biryukovmaxim/rus…
Demo: github.com/biryukovmaxim/rus…
Book: biryukovmaxim.github.io/rust…
So here's another—rather technical—component of the L1<>L2 design puzzle: The canonical bridge (entry/exit mechanism); see link down the thread.
Context
We are designing the bridge to support based zk rollup systems over Kaspa. We focus on the “based” setup as a first-class citizen, though other non-based approaches will presumably be possible. Being based in our context means that all transactions are directly submitted by users to L1, with some of them carrying payload data containing L2 smart-contract calls. This means L1 serves sequencing, settlement, and data-availability roles, while leaving only the execution (and proving) roles to L2.
1) Idk how user-friendly it is. But I believe this one can help understand deep details of the zk-based rollup covenant on Kaspa. biryukovmaxim.github.io/rust…
The main goal was a poc to get convinced we have all L1 capabilities needed
2) There's a room for optimization efficiency. @michaelsuttonil will share something interesting regarding that
Maksim Biriukov retweeted
I'm happy to announce Silverscript! (Link in reply)
Silverscript is Kaspa's first high-level smart contract language and compiler. It enables DeFi, vaults, and native asset management directly on Kaspa's L1.
The language syntax is based on CashScript, but adds essential features like loops, arrays, and function calls.
It specializes in managing contracts with local state (UTXO model), serving as a complement and infrastructure layer for vProgs (shared state).
Note: Powered by new script engine features recently enabled on Testnet-12. The syntax is experimental and might evolve.
Please try it out and give feedback!
















