Shin 𐤊aspa

Kaspa Japanese Community

[Shin 𐤊aspa @ShinKaspa]

明日45回目のカスパ振り返りです。暗号資産から離れていた方が今回の急騰で戻ってきてくれることを願っています。よろしくお願いいたします🙏

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

【第45回】Kaspaニュース振り返り！
🗓️8/23(日) 21:00(JST)〜

カスパパさん( @kaspapajp )と振り返ります✨

お盆明け回です！
#カスパ #Kaspa

https://t.co/dDUjls3tMt

[Shin 𐤊aspa @ShinKaspa]

第44回Kaspa振り返りスペースは日程を変更しての開催となります。よろしくお願いいたします！

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

⚠️日程変更のお知らせ
7/29(水)に開催を予定しておりましたスペースですが、都合により開催を翌日に変更させていただきます。
急な変更になり申し訳ありません🙇

【第44回】Kaspaニュース振り返り！
🗓️7/30(木) 21:00(JST)〜

カスパパさん( @kaspapajp )と振り返ります✨

https://t.co/2gOc490ahV

[Shin 𐤊aspa @ShinKaspa]

Kaspaの2週間振り返りです！ぜひご参加ください！

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

【第43回】Kaspaニュース振り返り！
🗓️7/9(木) 21:00(JST)〜

カスパパさん( @kaspapajp )と振り返ります✨

今回は木曜日です！
#カスパ #Kaspa

https://t.co/2sK3usENm5

[Shin 𐤊aspa @ShinKaspa]

今回のKaspa振り返りは週明け月曜日です！ぜひご参加ください🙏

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

【第41回】Kaspaニュース振り返り！
🗓️6/1(月) 21:00(JST)〜

いつも通り
カスパパさん( @kaspapajp )と！✨️

今回は月曜日です！
toccataハードフォーク直前回になりそうですね！

Kaspa周りの２週間を振り返りまーす👀

#カスパ #Kaspa

https://t.co/0PPcqrSO1o

[Shin 𐤊aspa @ShinKaspa]

40回目の振り返りとなります。よろしくお願いいたします。

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

【第40回】Kaspaニュース振り返り！
🗓️5/14(木) 21:00(JST)〜

いつも通り
カスパパさん( @kaspapajp )と！✨️

今回は木曜日です！
Kaspa周りの２週間を振り返りまーす👀

#カスパ #Kaspa

https://t.co/IVEDwfUlki

[Shin 𐤊aspa @ShinKaspa]

直近のKaspa DailyによるKaspa創設者ヨナタン・ソンポリンスキーへのQ&Aがとても分かり易くまとめられています。

#Kaspa #カスパ $KAS

[𝙆𝙖𝙨𝘾𝘼𝙋.𐤊𝘢𝘴 @Kaspa_CAP]

AIに読み込ませて解説してもらった
多くのカスピアンが思ってた事を言語化してくれた感じですね✨

⸻

「決済コイン論」ではない

YSはハッキリ：Wrong battle.と言った。つまり、店舗決済Visa競争“Kaspa Accepted Here”を主戦場と思っていない。
これはあなたが以前から感じてた：「人間向け決済だけでは終わらない」と近い。

「担保金融」方向

あなたが前に言ってた：「PoWは担保になる」これもかなり一致。
YSは：stablecoin時代のPoWはMoEより collateral（担保）と言っている。
つまり
Bitcoin = 重い担保
Kaspa = リアルタイム担保
みたいな方向性。

「待機資産（BoL）」という視点

これもあなたの：「金融インフラ価値」に近い。
YSは：Base of Liquidityという言葉で、「資本が一時滞在する基盤」を定義した。
これは単なる送金用途では説明できない価値。

「リアルタイム金融」

あなたは以前：「確認待ちを人間に合わせて、わざと遅くするUIになるかも」
と言ってたけど、YSの思想は逆に：裏側は極限までリアルタイム化する方向。
つまり人間UIはゆっくりでも、金融レイヤー自体はリアルタイム同期する。

「新しい市場」

あなたが直感していた：「今まで存在できなかったもの」
これもYSが：coordination marketsとして言語化した。
つまりKaspaは：既存金融の改善だけじゃなく、“待ち時間があるせいで存在できなかった市場”を狙ってる。

重要なのは
YS自身も言ってるけど、
「思想」≠「採用」

つまり
BoL
RTD
coordination markets
が本当に成立するには、実際にその市場が生まれる必要がある。
ここが次の壁。

でも逆に言うと
YSが今回ここまでハッキリ：
決済否定
L2否定
リアルタイム金融
BoL
coordination markets
を言語化したのは、Kaspaがもう「高速PoW実験」の段階ではなく、「何の文明インフラになるのか」を定義し始めた段階に来ている、という事だと思う

[Shin 𐤊aspa @ShinKaspa]

39回目の振り返りは明日です！よろしくお願いいたします！

kaspa:native #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

【第39回】Kaspaニュース振り返り！
🗓️4/27(月) 21:00(JST)〜

いつも通り
カスパパさん( @kaspapajp )と！✨️

今回は土曜日です！
Kaspa周りの２週間を振り返りまーす👀

#カスパ #Kaspa #Shinkaspa

https://t.co/9Yil4ZLGUW

[Shin 𐤊aspa @ShinKaspa]

もう38回目となった2週間振り返りですが、今週は土曜日の21時からです。ぜひ最新のニュースまとめを聞きに来てください🙏

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

【第38回】Kaspaニュース振り返り！
🗓️4/11(土) 21:00(JST)〜

いつも通り
カスパパさん( @kaspapajp )と！✨️

今回は土曜日です！
Kaspa周りの２週間を振り返りまーす👀

#カスパ #Kaspa #Shinkaspa

https://t.co/eGZimqRYqU

[Shin 𐤊aspa @ShinKaspa]

今回のKaspa振り返りは連休明けの月曜日です。ぜひご参加ください🙏

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

🎙️ Kaspaのニュース振り返り！
🗓️3/23(月) 21:00(JST)〜

いつも通り
カスパパさん( @kaspapajp )と！✨️

今回は月曜日です！
２週間+αを振り返ります👀

#カスパ　#Shinkaspa

https://t.co/rWXBtPFQya

[Shin 𐤊aspa @ShinKaspa]

今回は木曜日です！ぜひご参加ください🙏

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

🎙️ Kaspaのニュース振り返り！
🗓️3/5(木) 21:00(JST)〜

いつも通り
カスパパさん( @kaspapajp )と！✨️

今回は木曜日になります👀

最近、開発コア開発者が活発なkaspa！
２週間+αを振り返ります！

#カスパ　#Shinkaspa

https://t.co/dAIbbEaCo1

[Shin 𐤊aspa @ShinKaspa]

あらゆる効率や性能がAIによって評価される時代において、優れた技術が埋もれ続ける余地は急速に失われつつあります。

誇大広告や営業力ではなく、数学が支配する定量的な世界において、最も合理的な技術が選別されます。

#StudyKaspa

#Kaspa #カスパ $KAS

[Shin 𐤊aspa @ShinKaspa]

ヴィタリックが無個性なスケーリングL2は今後不要である旨の発信を行いました

Kaspa創設者は6年前にETHのL2主導構造の限界を予測しており、当初から今回ETHが提案している「同期的なコンポーザビリティ」が前提の並列SCフレームワークを構築しています

https://t.co/58IcCr2L3d

#Kaspa #カスパ $KAS

[vitalik.eth @VitalikButerin]

There have recently been some discussions on the ongoing role of L2s in the Ethereum ecosystem, especially in the face of two facts:

* L2s' progress to stage 2 (and, secondarily, on interop) has been far slower and more difficult than originally expected
* L1 itself is scaling, fees are very low, and gaslimits are projected to increase greatly in 2026

Both of these facts, for their own separate reasons, mean that the original vision of L2s and their role in Ethereum no longer makes sense, and we need a new path.

First, let us recap the original vision. Ethereum needs to scale. The definition of "Ethereum scaling" is the existence of large quantities of block space that is backed by the full faith and credit of Ethereum - that is, block space where, if you do things (including with ETH) inside that block space, your activities are guaranteed to be valid, uncensored, unreverted, untouched, as long as Ethereum itself functions. If you create a 10000 TPS EVM where its connection to L1 is mediated by a multisig bridge, then you are not scaling Ethereum.

This vision no longer makes sense. L1 does not need L2s to be "branded shards", because L1 is itself scaling. And L2s are not able or willing to satisfy the properties that a true "branded shard" would require. I've even seen at least one explicitly saying that they may never want to go beyond stage 1, not just for technical reasons around ZK-EVM safety, but also because their customers' regulatory needs require them to have ultimate control. This may be doing the right thing for your customers. But it should be obvious that if you are doing this, then you are not "scaling Ethereum" in the sense meant by the rollup-centric roadmap. But that's fine! it's fine because Ethereum itself is now scaling directly on L1, with large planned increases to its gas limit this year and the years ahead.

We should stop thinking about L2s as literally being "branded shards" of Ethereum, with the social status and responsibilities that this entails. Instead, we can think of L2s as being a full spectrum, which includes both chains backed by the full faith and credit of Ethereum with various unique properties (eg. not just EVM), as well as a whole array of options at different levels of connection to Ethereum, that each person (or bot) is free to care about or not care about depending on their needs.

What would I do today if I were an L2?

* Identify a value add other than "scaling". Examples: (i) non-EVM specialized features/VMs around privacy, (ii) efficiency specialized around a particular application, (iii) truly extreme levels of scaling that even a greatly expanded L1 will not do, (iv) a totally different design for non-financial applications, eg. social, identity, AI, (v) ultra-low-latency and other sequencing properties, (vi) maybe built-in oracles or decentralized dispute resolution or other "non-computationally-verifiable" features
* Be stage 1 at the minimum (otherwise you really are just a separate L1 with a bridge, and you should just call yourself that) if you're doing things with ETH or other ethereum-issued assets
* Support maximum interoperability with Ethereum, though this will differ for each one (eg. what if you're not EVM, or even not financial?)

From Ethereum's side, over the past few months I've become more convinced of the value of the native rollup precompile, particuarly once we have enshrined ZK-EVM proofs that we need anyway to scale L1. This is a precompile that verifies a ZK-EVM proof, and it's "part of Ethereum", so (i) it auto-upgrades along with Ethereum, and (ii) if the precompile has a bug, Ethereum will hard-fork to fix the bug.

The native rollup precompile would make full, security-council-free, EVM verification accessible. We should spend much more time working out how to design it in such a way that if your L2 is "EVM plus other stuff", then the native rollup precompile would verify the EVM, and you only have to bring your own prover for the "other stuff" (eg. Stylus). This might involve a canonical way of exposing a lookup table between contract call inputs and outputs, and letting you provide your own values to the lookup table (that you would prove separately).

This would make it easy to have safe, strong, trustless interoperability with Ethereum. It also enables synchronous composability (see: https://t.co/9jy6v1X6Fw and https://t.co/gZmu3YjebM ). And from there, it's each L2's choice exactly what they want to build. Don't just "extend L1", figure out something new to add.

This of course means that some will add things that are trust-dependent, or backdoored, or otherwise insecure; this is unavoidable in a permissionless ecosystem where developers have freedom. Our job should make to make it clear to users what guarantees they have, and to build up the strongest Ethereum that we can.

[Shin 𐤊aspa @ShinKaspa]

ある視点・時間軸に立てば技術はどうでもいいかもしれない。

しかし、優れた技術がもたらす恩恵を無視し続けられるほど歴史は甘くありません。
不合理な評価はいつも短命です。

[Shin 𐤊aspa @ShinKaspa]

「実行も並列」

vProgsの初期フレームワークが公開。

Kaspa × VProgsは、
「順序付け」と「実行」を分離・並列化することで、
DLT(分散台帳型)実行が縛られてきた
アムダールの法則の壁を壊す次世代SCエンジンを目指します。

#Kaspa #カスパ $KAS

[Hans Moog @hus_qy]

Have you ever looked at different DLT projects and realized they're all converging on the same ideas, just with different terminology?

And have you ever wondered what would happen if you forced all DLT projects to have a baby, where each could only contribute their most powerful ideas?

You'd be surprised by the overlap - how non-unique many projects actually are - and how few genuinely good ideas exist. Often they sound almost trivial once you strip away the noise.

The problem is that fundamental breakthroughs get buried under layers of unnecessary complexity - the inevitable result of gradually expanding a protocol's capabilities as research progresses.

With Kaspa, we have the benefit of being late. In fact, we're so late that we arrive at the party when almost all the research has already been done. We can skip the archaeology and just make that perfect baby - making the final breakthrough on our quest for perfection.

Today we are open-sourcing our vprogs framework: https://t.co/eCvvSAyt1n

A post-Amdahl execution engine that enables inter-block parallelism and linear scaling beyond boundaries traditionally assumed to be possible in the context of DLT execution.

By deeply understanding causal actors and domains, we eliminate almost all logic and instead encode behavior in dependencies and relational properties of a generic type framework.

This allows us to transparently map hardware resources to workload - achieving linear scalability.

The design principles:

- No fsync / WAL flush boundaries
- No mutexes / locks
- Versioned append-only data with efficient rollbacks
- Maximal parallelism - even inter-block - breaking through Amdahl's law
- No wasted CPU cycles on speculative execution

This repo is still heavily WIP with rough edges (we don't even prune state yet). But the goal of this repository is to create a concrete instantiation of all existing research directions condensed into a singular, maximally performant type framework that gets away with almost no logic.

There's still room for improvements (zero-copy deserialization, NUMA affinity, etc.) but we're converging toward a system that can eventually no longer be optimized or simplified.

The holy grail of blockchain execution isn't more complex but orders of magnitude less complex than anything that exists today!

I am really looking forward to tell you more about this in the coming weeks (I just ordered a new microphone pre-amp to be able to host regular hangouts where we can discuss and explain how everything works under the hood - let's pray for a fast delivery 😅).

[Shin 𐤊aspa @ShinKaspa]

あけましておめでとうございます。今年最初のスペースが開催されます。ぜひご参加ください！

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

明けましておめでとうございます🎍
2026年一発目のスペース開催です。

🎙️ Kaspaのニュース振り返り！
🗓️1/15(木) 21:00〜
カスパパさん( @kaspapajp )と振り返ります✨️

皆さんはいいお正月を過ごされましたか？
ぜひ遊びに来てください😊

#Kaspa #カスパ
https://t.co/5eGhNaiaL7

[Shin 𐤊aspa @ShinKaspa]

年内最後の2週間振り返りです。日本のカスパコミュニティの皆さん、今年もありがとうございました。良いお年を！

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

🎙️ Kaspaの2週間振り返り！

🗓️12/21(日) 21:30〜
カスパパさん( @kaspapajp )と振り返ります✨️

おそらく年内ラスト、
よろしくお願いします！https://t.co/NfHMIT5pap

[Shin 𐤊aspa @ShinKaspa]

恒例の2週間振り返りです。日曜開催はありがたいですね！ぜひご参加ください！

$KAS #Kaspa #カスパ

[Pan ‎𐤊 @kaspan_c]

🎙️ Kaspaの2週間振り返り！

🗓️12/7(日) 21:00〜
今回もカスパパさん( @kaspapajp )と振り返ります✨️

よろしくお願いします！

https://t.co/vsrDFnWBBK

[Shin 𐤊aspa @ShinKaspa]

17/17
✅将来的にはZKベースの階層化モデル（軽いノード + 証明ノード）を採用予定。

✅状態はバージョン管理で扱い、reorg時も巻き戻しやすいようになっている。

#Kaspa #カスパ $KAS

[Shin 𐤊aspa @ShinKaspa]

1/17
1. なぜ従来のブロックチェーンはスケールしにくいのか

🟣Solana（Sealevelモデル）の問題

Sealevel：Solanaの“並列エンジン”
複数トランザクションを同時に実行する。

ただし、トランザクションごとの依存関係（どのデータを書き換えるか）を揃えて並列化する必要がある

#Kaspa #カスパ

[Kaspa Eco Foundation (KEF) @Kaspa_KEF]

A one-pager recap of our space with @hus_qy yesterday for those who missed it.

@hus_qy is a veteran DLT researcher who worked on advanced consensus and parallel execution at @iota. After the project shifted direction, he left to pursue a blockchain that truly aligned with Nakamoto's idea, the decentralization values. @hus_qy found that alignment with #Kaspa—one of the very few projects still genuinely committed to the foundational ideals of cryptocurrency while also pushing the boundaries of high-performance blockchain design.

Now supported by KEF, @hus_qy is building #Kaspa's next-gen execution framework—modular VMs, DAG-based parallelism, and ZK-ready architecture.

[Shin 𐤊aspa @ShinKaspa]

16/17
まとめ

✅Solana/Aptosは「中央で順番を決めて並列化」するが、その調整がボトルネックになる。

✅Kaspaは「データの側が自律的に順番を決める」方式で、待ち・衝突・再実行のコストを回避する設計。