5bb55b

尝试升级到 Go 1.26 ，KRC-20 新节点的各组件运行良好。 得益于 GC 与 CGO 的底层优化，整体性能提升约 10-15% ，Lyncs引擎处理能力约 12K TPS on 16 Cores 。

@Valodeous I recall this was a "misunderstanding" caused by different field names in the API. I think we can fix it by adding a set of "v2" APIs (instead of changing the original ones).

Awesome that's much appreciated! On that note of token verification metrics, there was also a discrepancy between mainnet and tn10 for the kasplex indexer for burn total, circulating supply, and total supply. Previously tn10 indexer showed Burn Total but for mainnet, circulating and total supply were missing last time i checked and CMC is still showing unverified for all KRC20 projects as it auto updates in alignment with the indexer. I do sincerely appreciate all your hard work!

@Valodeous While not the main point, the top 100 holder statistics have indeed been implemented, if that's what you're referring to. Additionally, KRC-20 nodes will support a debug API, allowing direct access to raw data for all states.

@5bb55b Is this for mainnet to update the indexer to pull all the missing/incomplete data fields that CMC and CG require to verify token supply?

KRC-20 is about to reach its next milestone.

@kaspador_ No, I can't let you leak any more, hahaha.

Tell me more

@supertypo_kas @kaspa_stream @kasfyi Super thanks! Light-node are underway (via the new vspc2), which will allow for low-cost deployment and API compatibility.

First of all, I see a bunch of new contributors donating to @kaspa_stream since the @kasfyi ann. Very much appreciated🙏 I've started on krc20 support (token balances, history etc), to soften the blow. I hope kasfyi can be saved as getting everything right will take time.

@coderofstuff_ @IzioDev Fantastic! This will produce a series of chemical reactions. Super thanks @coderofstuff_ @IzioDev

PR740 by @IzioDev (and initially by DS) was just merged into the rusty-kaspa repo! This is a significant contribution that allows populated txs to be returned in RPC. It serves a lot of important use-cases needed for integrations such as: - being able to tell the source address (sender) of an accepted tx - being able to calculate the fee paid by a tx when it’s been accepted I’m sure exchanges (which need source address info), apps (like kasia who may need to know senders) and indexers (such as KRC20 which care about fees) would appreciate this info now being accessible. Exposing these properly to RPC required digging and understanding well how things are stored in Kaspa’s node consensus stores. An effort that @IzioDev undertook and pulled through! Kudos to you

@michaelsuttonil @kasplex @Kaspa_KEF @khriskang Thank you very much! I believe this would have been impossible without the help of you and all core members.

@kasplex @Kaspa_KEF Congratulations @5bb55b @khriskang

Kasplex zkEVM: Smart contracts arrive on Kaspa Layer 2 Kasplex, in collaboration with the Kaspa Ecosystem Foundation (KEF) @Kaspa_KEF , has officially launched its zkEVM Layer-2 mainnet, bringing Ethereum-compatible smart contracts to the Kaspa network. This launch represents more than just a technical achievement. It’s the first time that programmable dApps, DeFi protocols, and complex smart contracts can run on Kaspa; an ecosystem known for its ultra-fast, Layer-1 proof-of-work blockchain. For developers, it opens a brand-new design space; for the Kaspa community, it’s a leap into decentralized finance, tokenization, and beyond. Background: The foundation laid by “Crescendo” Kaspa’s Crescendo hard fork, activated on May 5, 2025, was a historic milestone for the network. Internally labeled v1.0.0, Crescendo was the culmination of years of research into blockDAG scaling Kaspa’s unique consensus innovation that allows blocks to be created and confirmed in parallel. Key upgrades introduced with Crescendo include: • Block rate increase: Kaspa’s throughput jumped from 1 block per second (BPS) to 10 BPS, multiplying raw network capacity by a factor of 10. • Transaction ordering improvements: Ordered transaction execution was made possible; an essential prerequisite for any Layer-2 that relies on determinism in state changes. • Layer-2 readiness: Protocol updates for latency reduction, parallelism, and data availability ensured that Kaspa could support zk-rollups and other scaling solutions. • Developer foundations: By upgrading the underlying infrastructure, Crescendo essentially “primed” Kaspa for programmable logic, while retaining its hallmark instant confirmation and finality. Without Crescendo, Kasplex would not have been possible. It transformed Kaspa into a foundation ready for programmability at scale. What Is Kasplex zkEVM? Kasplex is the first zkEVM rollup deployed on Kaspa. Kasplex inherits Ethereum compatibility, meaning that developers can use the same tools they already know Solidity, Hardhat, Remix, Truffle, MetaMask without learning a brand-new development stack. Deployment is as simple as redirecting RPC endpoints. Some of Kasplex’s defining features include: • Gas in $KAS: Unlike most L2s that introduce a separate token, Kasplex uses bridged $KAS from Layer-1 as the native gas token. This preserves economic alignment and keeps value within the Kaspa ecosystem. • Bridging mechanism: A two-way bridge enables users to move $KAS from L1 → L2 to use in smart contracts, and back from L2 → L1 seamlessly. • Open node infrastructure: Kasplex offers three types of nodes that anyone can run, ensuring decentralization rather than limiting validation to a closed set of operators. This is more than a technical upgrade, it’s a strategic expansion for Kaspa: • For developers, Kasplex lowers the entry barrier: if you can code on Ethereum, you can now code on Kaspa. • For users, it means fast, low-cost DeFi, NFTs, DAOs, and experimental applications all secured by Kaspa’s proof-of-work Layer-1. • For the ecosystem, it’s the bridge to mass adoption: Kaspa goes from being a high-throughput Layer-1 to a complete smart contract platform. L2 Testnet: Key metrics & early performance Here are some of the notable statistics from Kasplex’s testnet since launch • Blocks generated: ~ 6.5 million (Kasplex does not generate empty blocks); blocks are produced only when there is payload to commit from L1. • Transactions: ~ 24 million • Unique wallets: over 300,000 • Throughput: over 1,000 transactions per second (tps) • Average block time: 0.9–1 (bps) These numbers speak to robustness, stability, and growing adoption. They suggest the system is performing well under load. Components Here’s how Kasplex is structured, and what its ecosystem includes: • Two-way bridge: Supports transfers from L1 → L2 → L1, so users can move $KAS into the Layer-2 environment, use them for gas/contracts, then exit if needed. kasbridge-evm.kaspafoundation.org • RPC / API: Full RPC endpoints supporting EVM-compatible calls evmrpc.kasplex.org • Explorer: Blockchain explorer for viewing transactions, blocks, and smart contract state on L2. explorer.kasplex.org • Chain ID: 202555 (this is the identifier for the Kasplex Layer-2 chain). • Token: $KAS • Official website: kasplex.org • Documentation: docs-kasplex.gitbook.io/l2-network • Layer 2 audit: github.com/kasplex/evm-l2… • Community: linktr.ee/kasplex What’s Next: Roadmap & Upgrades Kasplex is not static; several future developments are in motion: • KRC-20 (Kasplex’s token/inscription standard) will receive important upgrades before year-end. • A new EVM-Lua interface is in development that will allow for alternative smart contract languages or scripting paradigms. • Further Layer-2 functionality upgrades leveraging innovations from Kaspa itself (for instance, zero-knowledge proof improvements, “vprogs” or virtual programs, etc.). Why this matters: Implications for Kaspa & the ecosystem • DeFi readiness: Kasplex unlocks detailed smart contracts and composability, enabling AMMs, lending/borrowing, stablecoins, and all the tools of decentralized finance. • Developer onboarding: Because it’s zkEVM + Ethereum‐compatible, porting existing dApps is much easier. This will accelerate ecosystem growth. • Scalability with security: Kaspa’s PoW + blockDAG architecture combined with Kasplex’s roll-up design aims to maintain strong security and decentralization. • KAS utility: Using $KAS as the gas token helps retain economic alignment, not relying on an external token. Closing thoughts We extend our sincere gratitude to the Kaspa core developers, whose groundbreaking work made this possible, and to the Kaspa community, whose vision and energy continue to inspire us. A special thanks goes to all the teams and builders who tested their applications on the Kasplex testnet, providing invaluable feedback that helped shape the mainnet launch. Kasplex zkEVM is not just our achievement, it is the result of collective dedication, collaboration, and belief in what Kaspa can become. This milestone belongs to all of us, and it marks just the beginning of what we can build together.

I don’t know much about Sparkle, but I think it’s a system at different levels. Sparkle looks like a more complex infrastructure at the bottom level, but the Lua-based VM provides a simplified implementation of the application layer. It is lighter and faster than solidity-EVM, but still slower than golang.

@5bb55b @plzsats So, like sparkle, but much faster available? (And eventually different programming language but who knows)

EVM means a fixed technology path (with bloated compatibility builds), which is certainly true. But we can also explore other possibilities after untying some old shackles. For example, it can easily implement parallel computing, has very simple and easy-to-learn programming syntax, and has relatively faster execution speed, etc.

@5bb55b @KASPA_ZH What is main differences between zkEVm and newvm?

@Dodo13080274 我确实更喜欢轻量级的各种东西😆。

@5bb55b 不对 那会儿英国还是notepadplus 红色的icon 该死的记忆开始侵袭为了

If we wrote the contract in Lua.

@oneforonehaha @SentinelKaspa @kaspador_ @Kaspa_KEF @kasplex It is still a very early experimental version. As an open SC environment, it still needs at least two modifications to the underlying mechanism, but it is sufficient for the system contract of KRC20. Next, I need to tune the performance.

@SentinelKaspa @5bb55b @kaspador_ That is not a question for @Kaspa_KEF but for @kasplex. Maybe this is the LuaVM not related and in parallel to EVM, or maybe Kasplex team is still figuring out how to use KRC20 to raise funds before they can get ready.

@shit_o_shi As an embedded scripting language, it is very lightweight and fast (with the JIT-compiler). I think that in some specific application scenarios, it is not worth making things too complicated or even creating a new language😃.

@5bb55b Interesting choice if you go with Lua, what are the main drivers for it? 🤔

@michaelsuttonil @skibumtrading I think we can use features of KIP10 (and maybe some additional ones).

I don’t want to say too much, but it’s kind of an initial limitation of avoiding long-term state (ie focusing on short term episodes/games) in order to speed up the deployment of this engine. What ever we’re doing here, I’m not talking a big dev effort, but rather doing a first minimal version in the right way so that the community can takeover

I know I promised a cool post, but I’ve concluded we should finalize the infra/prototype code first so that we can open source it along with the post explaining the concept. Please bear with me a little longer. sneak peek: the raw idea is a fast/immediate path for vibe coding episode-based kdapps. --- General roadmap post tbd and will take longer.

@coderofstuff_ @michaelsuttonil Ahaha, thank you😆, I might try to make some small functional changes to the node to help understand it.

@5bb55b @michaelsuttonil Please feel free to dm me anytime for any technical questions about the node and I’ll try to answer or guide you to the answer

Yup, as far as I can tell from an initial scan the generated docs are of high quality. I didn’t spot blatant lies/ errors/hallucinations. It can use more context and additional info in some places and I’ll try to put time into improving it through the available apis they have

From the perspective of the concept of the protocol and the user interaction experience, my personal suggestion is that wallets or any place where tokens are displayed can clearly distinguish between two different modes (mint or issue), and for the issue mode, it is necessary to display the beginning and end of the ca. In another sense, the unique ticker in the mint mode has a certain scarcity attribute.

In addition to the updates mentioned below, we've now refreshed the relevant information in our documentation. You can now learn how to issue, blacklist, burn, and more using the new node. Check out the updated guide: krc20.gitbook.io/krc20/protocol…

@Dodo13080274 区块链领域还是更需要开放式交流，对我而言必须持续高速学习，虽然写了20年代码，但进入这个领域也就两年不到，惯性谦虚哈哈。

概念太多，教育太多 产品落地才是目的，才是大结果的前提