Kaspa

a few unrelated observations/notes 1. @manyfest_ recently made me realize that beyond the obvious point that covenants on Kaspa can serve as first class state machines, they also have 2 significant properties: • they are lightweight: on chain we store commitments to rules/state, and txns provide the witnesses for changes (transient cost vs persistent contract storage/rent) • they can be entered atomically (multiple parties can create and enter into the covenant in one txn) the last two properties seem to have significant potential in the agentic era. agents can define custom rules and agreements between them without deploying a contract (compare this to eth/sol contract/program). covenants are a fast, lightweight tool for such agent-to-agent rule systems. 2. Kaspa is reentering the GPU era. Kaspa r&d is already experimenting with several GPU workstations for zk proving. 3. @coderofstuff_ is doing fantastic work advancing dk in parallel to covpp work (and making sure the content of my long-overdue, unshared post gets shared nonetheless) x.com/i/status/20278…

Dagknight technical progress As would be mentioned in a still unshared post by @michaelsuttonil, the dagknight effort is split into v0 devnet, v1 testnet and v2 mainnet candidate. I’ve been testing the current v0-based implementation in a small devnet with the help of some testers who run nodes and miners with me. The DK work can be thought of as split into two parts: (1) implementing the actual protocol and (2) wiring it up and using it. The testing and development over the last month has been focused on (2). Obviously, DK is a consensus change for selecting parents. What’s not so obvious is that such a change affects DAA, coinbase, IBD, pruning and a lot more. Each of these areas is very sensitive and requires proper understanding to wire correctly. An important consideration and difference from GD is that DK does not focus on maximizing a property like blue work. So to maintain topological properties of blue work, an independent (free) GD implementation is kept running specifically for maintaining blue work. This allows us to keep using the property for topology. Coloring and blue score use the megachain induced by DK. The wiring around DK as of this posting is in a working state, but still needs to be reviewed. Next efforts will be focused on protocol specific components, particularly Tie-Breaking and incremental UMC. Attached are some captures from the internal devnet. The dense DAG image is what happens when things related to DAA or other similar consensus parameter causes a node to insist on their POV. The video is a recent snippet of the KGI running on the devnet showing (perhaps not obviously) DK at work. The current “dagknight” branch is now posted on the main repo. A topic in the Public R&D has been opened for Dagknight development.

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/rusty-kaspa/ch… The main goal was a poc to get convinced we have all L1 capabilities needed

Anyone know how to see the current UTXO set size for Kaspa? $KAS #Kaspa

Today there is a bigger update because there are 3 new PRs that are ready for review. The first one (github.com/kaspanet/vprog…) fixes some bugs and introduces the SchedulerState which unifies the way we expose shared state in our framework. The second one (github.com/kaspanet/vprog…) introduces the node-framework which builds on top of the first PR and introduces a generic platform for building L2 nodes that ingest data from the Kaspa L1 to produce state changes (and eventually proofs) of the L2-execution. The third one (github.com/kaspanet/vprog…) introduces the node-vprogs-cli - an actual binary that can be executed and that follows the L1 to execute transactions in a concrete VM. The binary is designed to support compile-time modularity, which means that by updating a single line in the backend.rs we can swap out both, the storage and the VM. A VM is defined by three functions: 1. A pre_process_block function which extracts the relevant L2 transactions from the L1 chainblock. 2. A process_transaction function which executes a single transaction (within its scope) and produces execution-results. 3. A post_process_block function which takes the execution results of the individual transactions and stitches them together into an aggegrated proof structure which can be settled on the L1. All steps are parallelized as much as the underlying causal structure permits. I still have a few chores on my todo-list and there are still a few missing parts (like syncing from state that we didn't actively witness) but this is pretty much as far as we get without re-integrating with the covenants on L1, so the next steps will be to actually design the concrete framework for settling state transitions on the L1 (and consequently syncing from it). I suspect that this will require a little bit of back and forth between the two development efforts but we are getting to the point where things start to get interesting.

Today we're announcing that we have been actively mining Kaspa. Diversification has been key to our investments in energy solutions and tech innovations, and it remains crucial in our digital asset compute operations. Read the full press release: ir.mara.com/news-events/pr…

@kaspaunchained honestly sub-second confirmations without L2 workarounds is pretty wild 🔥 been watching crypto infra for years and most "fast" chains just add complexity layers this sounds like actual architectural innovation - gonna have to dig into GHOSTDAG

We see that there are many of you who are eager and curious about the hackers projects! Great to see enthusiasm from the community! 😄 You can get a sneak peak at the early submitted projects, but remember that they are still building and editing until the deadline. We're at 240 hackers now, so definitely more to see soon! #Kaspathon #Crypto $kaspa #Hackathon dorahacks.io/hackathon/kasp…

@NakaSompo #Kaspa exists because true L1 scaling was left unexplored, not impossible.