Happy 5th birthday Kaspa!
so young, and carrying so many hopes,
already rusty, yet smooth on your feet.
you’ve danced through crescendos, quickening (y)our beat,
then a toccata, a covenant bond --
our trust in your hands, your future in our care.
a knight drawing near, swift and hard to sway,
keeping time with the world, come what may.
whole worlds to build, and silver ink to dream them in --
im(.ag)ine all the songs still waiting to begin
two years ago, when we were designing based rollups/apps over kaspa with canonical bridging etc, did we have this privacy use case in mind? at least for me, no.
(see posts here:
https://t.co/QXbfQiGHWr
https://t.co/EWw6y6ygz1 brainstormed with @dimdumon, @hashdag and @VolokhIlia)
seeing these ideas now being explored for privacy is a reminder of why infrastructure work needs to be sound, diligent and forward thinking. you can’t anticipate every application, but thinking carefully about the foundations can make room for things you hadn’t specifically imagined.
eg with the canonical bridge, the core idea is a pool of resources whose internal distribution is managed by the L2 app state and opaque to L1. this seems to map cleanly to the proposed privacy architecture, with an additional layer where each user’s private state is hidden from everyone else and the app itself verifies user proofs as part of its execution/proving (worth mentioning that these user proofs need not be directly compatible with L1 zk opcodes, only the outer app proof needs to be)
same goes for kip21 and proving work proportional to app activity, which seems rather useful and important here as well.
one more thing i wanted to add here (and we discussed), @WellerOlaf: the based component not only provides censorship resistance but also gives in-app confirmation times driven by L1 frequency and not proof frequency. once an operation is ordered and its execution locally validated, every possible prover is bound to that outcome. no valid proof can advance past it while skipping or changing it
Unpopular opinion:
If your “Kaspa adoption” project only targets people already holding kaspa:native , you’re not growing adoption, you’re recycling the same audience and liquidity.
Real adoption is building something outsiders actually want, then making Kaspa part of that experience.
Otherwise, you’re not onboarding new users. You’re monetizing the existing ones.