Rusty Kaspa Workshop #3 was a two-hour codebase walkthrough led by Michael Sutton and Hans Moog on June 4, 2025. It used pruning logic, multi-level BlockDAG relations, header compression, and live diagrams to give proficient developers enough context to begin exploring useful, non-consensus-critical optimization work without oversimplifying the protocol.

Key takeaways

• The workshop began with pruning because bounded node storage is central to long-running network operation.
• Kaspa pruning is more complex than deleting old entries from a single chain.
• Live code and diagrams connected multi-parent DAG relations to implementation details.
• The suggested entry points focused on non-critical optimizations suitable for onboarding contributors.
• Watching a recording is a starting point; any code change still needs tests, benchmarks, review, and current repository context.

What did Rusty Kaspa Workshop #3 cover?

KASmedia’s June 9 recap reports that core developer Michael Sutton and programmer Hans Moog co-hosted the session in the Kaspa Discord, with a full recording later made available on YouTube. The workshop walked through code line by line and paired it with drawings of Kaspa’s BlockDAG.

The central subjects were pruning logic, multi-level relations, pruning inefficiencies, and possible header-compression strategies. Those topics sit at the boundary between protocol understanding and systems engineering: developers must understand what historical information remains necessary before attempting to reduce its storage or bandwidth cost.

Why is pruning difficult in a BlockDAG?

In a simple mental model of a blockchain, blocks form one ordered line. Kaspa allows parallel blocks and orders them through GHOSTDAG, so the data structure includes multiple parent relationships and a richer history. Removing old data therefore cannot mean “delete everything before height N” without considering the proofs and relations required to validate the remaining state.

Pruning aims to let a node discard historical material that is no longer needed for normal operation while retaining enough information to verify the accepted state and synchronize safely. The exact boundary is consensus-sensitive even when a proposed storage optimization is not. A mistaken assumption can prevent a node from validating data or serving peers correctly.

What are multi-level relations?

Kaspa’s implementation uses levels to organize aspects of the DAG and its reachability or proof structure. The workshop’s live drawings helped participants map those abstract relations to concrete code. That teaching method matters because names such as “parent,” “selected parent,” “level,” and “pruning point” have precise meanings that cannot be safely inferred from ordinary graph terminology.

New contributors should build a glossary while following the code. Note where a type is defined, which service owns it, whether it is consensus-facing, and which tests establish its invariants. This reduces the risk of treating a cached representation as the source of truth.

Why was header compression discussed?

Block headers are transmitted, stored, compared, and indexed frequently. At scale, even modest reductions can affect bandwidth, disk use, cache efficiency, and synchronization time. Header compression explores whether redundant or derivable information can be represented more efficiently.

The tradeoff is complexity. A smaller representation is not automatically better if it increases CPU cost, complicates recovery, creates versioning hazards, or obscures consensus validation. A credible proposal therefore needs measurements on representative data, an explicit compatibility story, and adversarial tests—not merely an attractive percentage reduction.

What made the workshop useful for new contributors?

The hosts reportedly emphasized non-critical optimization tasks. That is a sensible onboarding path: a contributor can learn workspace structure, benchmarks, tests, review standards, and performance tools without beginning with a consensus-rule change.

A practical sequence is to reproduce the official build, run the existing test suite, profile one documented workload, and select a narrowly scoped issue. Before coding, search open pull requests and ask whether the task is still relevant. The recent guide to Rusty Kaspa on Windows shows how even a small build fix benefits from a precise cause, bounded patch, and documented exit plan.

How should a developer study the recording today?

Use the recording as historical instruction and the repository as current authority. Check out the source revision discussed in the session if you want line numbers to match, then compare it with the current master branch. Code moves; concepts may survive while file paths and interfaces change.

Pause at each diagram and locate the corresponding types and tests. Write down questions that can be answered through code search. When a statement appears to describe an invariant, find the test or proof comment that enforces it. This turns passive viewing into a reproducible learning exercise.

What would count as a good first contribution?

A good first contribution is measurable, reviewable, and reversible. Examples include improving documentation, adding a missing regression test, reducing an allocation on a non-critical path, or creating a benchmark that exposes an acknowledged inefficiency. It should avoid changing consensus semantics unless the contributor has the required context and reviewers explicitly agree on scope.

The broader June 2025 Kaspa testnet roundup also illustrates paths outside core consensus: wallets, developer tools, test harnesses, and ecosystem applications need careful contributors too.

Frequently asked questions

Was Workshop #3 a beginner programming course?

No. It was positioned for proficient developers who were new to Kaspa and needed background to navigate the Rusty Kaspa codebase.

Did the workshop announce a pruning consensus change?

The cited recap describes education and optimization discussion, not a mainnet activation announcement. Any later proposal must be evaluated through its own source and release process.

Can developers safely copy code from the recording?

They should first match the historical revision and inspect the current repository. Interfaces, tests, and accepted practices can change after a recording is published.

Source and verification note

The primary source is KASmedia’s June 9, 2025 report, The Weekly Knight: Highlighting Kaspa’s YouTube Community, which links the workshop recording and identifies its hosts and topics. Current implementation details should be verified in the official rusty-kaspa repository.