The post Kaspa and Bitcoin…What’s the Difference? appeared first on Kaspa.

The post Due Diligence Checklist for Kaspa Apps and Dapps appeared first on Kaspa.

The post Why Kaspa Succeeds Where Millions of Crypto Projects Have Failed appeared first on Kaspa.

Guests: #Kasplex @kasplex
and its founder @5bb55b

Transcripted & Translated by the bot of Dr. Jason.
Reviewed by SHL, Captain Sats @plzsats

Original Twitter Link:

https://twitter.com/kaspa_chinese/status/1784818356597789141

Feedback Link: https://docs.google.com/document/d/13OBCK777sohL9VI7CA87PJnLAZ6VXOomlRvwu_gaDGs/edit?usp=sharing

Phase 1-Introductions to Kasplex：

BadSucker666 (Dr. Jason):

First, let me provide some background. Recently, the Bitcoin ecosystem has evolved from BRC-20, ARC-20, and others to the launch of the runes protocol. The inscription system is continuously undergoing technical iterations and evolution. However, issuing protocols similar to runes on Bitcoin, whether in terms of implementation methods or the overall potential of the protocol, actually differs significantly from Kasplex.

For instance, runes is designed based on the OP_RETURN field and is limited by Bitcoin’s throughput, which constrains its scalability. Current speculations suggest that Kasplex is based on a completely different design using public key addresses. Everyone is looking forward to Kasplex becoming the standard for asset issuance under the Kaspa asset protocol. Next, 5bb55b will introduce us to the project vision and team nature of Kasplex.

5bb55b (Head of Kasplex):

First, I’d like to thank the host, Dr. Jason. I am honored to be invited to participate in this space. As one of the developers, I will give a brief overview of Kasplex. Actually, our official Twitter hasn’t started formal publicity due to the tight schedule and some technical content involved. So, I’ll try to keep it simple and understandable.

Next, I will cover several aspects, as Dr. Jason mentioned our project vision and team nature, the concepts of smart contracts and data inscriptions, and their similarities or complementary aspects.

Then, I’ll introduce the Kasplex protocol, including some features, followed by a brief Q&A session.

Let me start with the first part. As the first ecosystem protocol on Kaspa, Kasplex aims to facilitate the issuance and circulation of various assets through on-chain data inscription. There will also be continuous iterations, hoping to serve as the infrastructure for Kaspa’s potential future Layer 2 ecosystem.

Regarding the team, we are a non-profit project, mainly funded by KEF for major developers, that is, myself and Khris. Khris is also the project manager of Kasplex, but he couldn’t attend today as he just got off the plane. He is a very senior professional in the web3 industry, and I am a seasoned practitioner, but not particularly outstanding. Another clear point is that our team only develops protocols and related open-source systems, and does not deploy or issue any assets.

Let me first briefly introduce how to understand smart contracts and data inscriptions (i.e. Data inscriptions on BTC)? Why do I start with this? Because I see that many in the community think that we should not follow BTC’s approach to inscriptions, runes. I have heard different opinions, and there seems to be some confusion.

First, I’d like to share my view that data inscriptions and smart contracts are two on-chain scaling solutions that can coexist and complement each other.

A smart contract is a piece of code that can process data in different ways. It doesn’t change the blockchain when developing apps. Just create the contract code to implement the program logic. ERC-20 is an example of a smart contract. Also, various DEXs (decentralized exchanges) are pieces of code. Some of them can be really complex, like Uniswap.

Can tokens still be issued without smart contracts? Many people think not. Actually, it is possible, but how? I’ll explain briefly. We can try to understand a smart contract. A smart contract has three parts: input data, logic processing, and output data.

The input data is a set of instructions for an operation. The logic processing is like a virtual machine that runs the code. The output data updates the state after the final execution. For example, an increase of 100 tokens at a certain address is the output.

Now it comes to the second part, what then is data inscription? We write data with special meanings into on-chain transactions. This helps to keep the blockchain network secure. The consensus mechanism ensures that the inscribed data won’t be changed. This is where the idea of inscription comes from. In the Kasplex protocol, we put the input data on the chain. For the second part, we create a set of protocols.

Finally, we can derive the third part, the output data. More specific details can be seen in the white paper soon to be released on our official Twitter, which everyone can follow.

Many people have an aversion to inscriptions, which actually stems from two aspects: first, BTC itself is very slow, very expensive, and unable to support any so-called “BTC Ecosystem”. I believe BTC is perfectly suited as a store-of-value, and it certainly does not need any ecosystem. Second, BTC’s inscription or rune protocols possess some very poor characteristics. I’m not sure whether these were accidentally caused or intentionally designed that way.

These two points have led to some very bad situations, such as severe network congestion, insanely expensive gas, and hindering the normal transfer operations of users B, C, and D.

Inscriptions also generate a lot of UTXO dust, which quickly fills up the node state dataset. Nodes need better hardware. Inscriptions and runes are also prone to burning because they are tied to UTXOs. This means that UTXO dust can only be created, not merged. Once merged, the inscription assets are gone, which is bad.

The above introduces the technical principles of smart contracts and data inscription. Next, we’ll look at some features of Kasplex. Kasplex has three main parts: the data inscription protocol, which defines how data is written into chain transactions. It will also include various specific application scenarios, such as KRC-20 is the protocol for token issuance, and later there will be KRC-721 for issuing NFTs. Second, the open-source indexer scans and processes on-chain data. Third, we will provide query APIs. If you can’t run a node, you can query balances or transfer TX records through public APIs.

I won’t go into too much about technical details here as many of our audiences are non-techy. But stay tuned! Kasplex’s roadmap and white paper will be released on our official Twitter soon. Most of the details will be there.

We started technical research at the beginning of the year to create the core inscription protocol. We found that using Kaspa as the main chain for data inscription is perfect. I won’t talk much about how Kaspa solves the trilemma. Those who know, know. We spent a lot of time thinking about how to coordinate the data inscription protocol with Kaspa’s advanced features. Kaspa’s high bandwidth and throughput ensure a good experience under high-frequency operations. Its pruning mechanism avoids data sedimentation. These features are unique to this chain. We don’t use BTC’s Ordinal model. It’s a bad mechanism. Kaspa’s transaction fees are low, wallets can merge UTXOs at any time, and there’s no need to worry about burning assets. We will also add a new fee model to the protocol. It helps the network and makes miners richer. Some operations, like deploy or mint, will cost more, but this goes to the miners. Other operations, like transfers, will still be very cheap. This is to ensure that normal transfers are not affected. This doesn’t affect Kaspa transfers or issued token transfers.

The Kasplex protocol will provide a decentralized on-chain market solution in phase two. It can be used by wallets or market applications to trade tokens. It will share all orders. If your token is listed in wallet A, then wallet B or market C can see and trade it. The white paper has more technical details, including how data is chained, the protocol’s rules, etc. I’m in charge of developing the open-source indexer. The first phase will implement basic token deployment, minting, and transfer. It will soon be tested on the testnet and will soon assist various wallets and browsers. More info coming soon on Twitter.

Phase 2-Q&A：

BadSucker666 (Dr. Jason):

Thanks, 55b. First, I have a question. Sutton posted some thoughts about Kasplex on Twitter. Were his guesses right? If so, could you share more? Sutton guessed that it would involve storing the hash value of the inscription data as a p2sh address on the chain.

5bb55b (Head of Kasplex):

I would say almost 100% correct! In fact, Sutton’s approach is more aggressive. We encode the data in JSON and upload it to the chain in ASCII. There are also some other complex cases, and not all are ASCII-encoded text. You can check more details in the white paper.

BadSucker666 (Dr. Jason):

Next, let’s move on to the Q&A session to see if the audience has any questions, and we can discuss further.

Li Xianyu (Moderator of the Kaspa Chinese Community):

From a user’s perspective, I have some questions: How do users utilize Kasplex after its release? For example, is it a desktop executable, or something like a browser extension that we can use out-of-the-box? Can third-party wallets make transfers, or how does it work?

5bb55b (Head of Kasplex):

Well, your wallet is basically the entry point for asset queries. As long as the integration follows our protocol, both wallets and browsers can operate just fine.

Li Xianyu (Moderator of the Kaspa Chinese Community):

So, you’re saying we will use wallets like OKX Web3 Wallet and others that support it, am I right? Can you share any information about which wallets will support this in the first phase?

5bb55b (Head of Kasplex):

I can’t say much yet. We’ll have to wait for the roadmap. The KasWare developers are here today and eager to integrate. As I said, our protocol is open-sourced, anyone can use it at any time.

Li Xianyu (Moderator of the Kaspa Chinese Community):

I see. You just provide APIs that can be called by anyone who wants to integrate.

5bb55b (Head of Kasplex):

That’s right. You can follow our documentations and white paper later to integrate. Moreover, if you don’t want to use the APIs we provided, you can run your own indexer, run your own node, and deploy your own APIs. Everything is completely open-sourced.

Li Xianyu (Moderator of the Kaspa Chinese Community):

Understood. Are there any wallets that are ready to cooperate at least for the public test?

5bb55b (Head of Kasplex):

There definitely will be by the time of the public test. Because if the wallets aren’t ready, we won’t start the public test.

Li Xianyu (Moderator of the Kaspa Chinese Community):

So, the internal test uses the TN11, right?

5bb55b (Head of Kasplex):

That’s correct.

Li Xianyu (Moderator of the Kaspa Chinese Community):

How do we participate in the internal test?

5bb55b (Head of Kasplex):

Well, the internal test is generally not for the general public. Our development team is running stability tests and fixing bugs. If you need help integrating wallets or browsers, we can help.

Li Xianyu (Moderator of the Kaspa Chinese Community):

Do you have a date for the public test? Like June or some other month?

5bb55b (Head of Kasplex):

I can’t confirm yet. It depends on the internal test.

Li Xianyu (Moderator of the Kaspa Chinese Community):

OK. Does anyone else have any questions?

Questioner 1:

1. Who is the founder of Kasplex?
2. Has there been communication with the official Kaspa team? I’m concerned about a lack of official support.
3. Will the KRC-20 upgrade in the future, similar to how inscriptions changed from four to five characters? Can it implement smart contracts?
4. The KRC-20 protocol is said to enable the issuance of stablecoins, how is this possible?

5bb55b (Head of Kasplex):

First, follow the developers @5bb55b and @khriskang and the official X @Kasplex.

Second, we have communicated many times with the core development team, who will not intervene in our protocol development. However, they generally approve of us. Our protocol will fully comply with the rules of Kaspa nodes. For example, we strictly follow KIP-9 concerning the prevention of dust UTXOs. Essentially, Kaspa nodes set the major rules, and we establish smaller ecosystem applications within those rules.

Third, regarding the iteration of the Kasplex protocol, the project will be under long-term development, which I see taking at least a year or two. The first phase is just some basics, similar to BRC-20 strategies. Many more things will be disclosed gradually. Additionally, regarding smart contracts, as I mentioned earlier, it is a soil of unlimited innovation. The KRC-20 or Kasplex protocol isn’t a smart contract per se, but it can achieve some of the functionalities that smart contracts do.

Fourth, the essence of stablecoins is still coin issuance. It requires institutions qualified to issue stablecoins to handle it, which is beyond the technical aspects. Our primary goal is to support asset issuance. Whether stablecoins will be issued in the future depends on whether there are qualified institutions to issue coins on the Kaspa mainnet. Actually, this is beyond the scope of Kasplex protocol development.

Questioner 1:

The inscriptions on BTC cause a lot of junk data in nodes. How does your protocol solve this problem? To what extent does it reduce such junk data?

5bb55b (Head of Kasplex):

That’s a great question. When we started designing the protocol, including during our research, we focused on this issue first. So, why do BTC’s inscriptions cause UTXO bloating? Because BTC’s UTXOs are tied to inscription assets, and those UTXOs have to be left untouched; using them means they’re gone or transferred. We do not adopt this scheme. That is to say, your UTXOs can be merged and used at any time, without affecting any of your inscription assets at all. You could say our protocol completely avoids causing UTXO dust or bloating.

Li Xianyu (Moderator of the Kaspa Chinese Community):

Will the public test run on the Kaspa mainnet? Can you give an estimated time?

5bb55b (Head of Kasplex):

I cannot confirm right now, I really don’t know. We’ll have to see how things go, but everyone should just follow our official Twitter for updates.

Questioner 2:

I want to ask, is Kasplex going to be a foundational infrastructure? After establishing the KRC-20 infrastructure, can other projects run on it?

5bb55b (Head of Kasplex):

Yes, that’s one of our goals. We also hope that many project developers will use our protocol for various applications, whether it’s issuing tokens or building other functionalities.

BadSucker666 (Dr. Jason):

Let me briefly summarize what 5bb55b just mentioned about the framework, which I think is particularly good. Kasplex breaks it down into three core steps: 1. How we write data on the Kaspa chain, which you’ve already answered thoroughly, and if anyone wants to know more, they can check out Sutton’s Twitter. 2. Kasplex acts as an indexer with its own processing logic. We still need to run the indexer separately to execute the protocol’s logic. 3. After execution, how do we write the data back to the chain? My question is whether the form of writing back in the third step is the same as the first step?

5bb55b (Head of Kasplex):

Actually, there is no write-back currently. Everything is maintained by the indexer. The indexer is open-source, and everyone can run it themselves.

BadSucker666 (Dr. Jason):

You just mentioned the future upgrades of the Kasplex protocol. For example, changes in the data format written, and changes in protocol processing logic in the future, how will these be addressed?

5bb55b (Head of Kasplex):

There will be continuous iterations, but they will definitely be backward compatible. The technical details will be in the white paper, and we will also implement mechanisms like hash trees to ensure the accuracy of the final output state.

BadSucker666 (Dr. Jason):

Issuing stablecoins requires high security. Currently, the security of Kasplex is based on the main chain. My question is, are there any inherent security risks in the Kasplex protocol itself, or do we have secure designs?

5bb55b (Head of Kasplex):

Yes, similar to the hash checks and hash tree verifications I just mentioned. There might even be some decentralized solutions, which you’ll need to check the white paper for details.

BadSucker666 (Dr. Jason):

OK. I see someone asked what are the advantages of using KRC-20 for Memes? Personally, I think it mainly depends on the differences between Kaspa and Bitcoin, as protocols like runes on Bitcoin are limited by its block generation speed. Kaspa will definitely be especially smooth. Including the upcoming full upgrade to rust nodes, reaching 10 bps will be very fast. This should be a significant Buff to KRC-20. I wonder how 5bb55b views the impact of Kaspa mainnet upgrades like 10 bps, DK, etc., on Kasplex?

5bb55b (Head of Kasplex):

Actually, only after the 10 bps goes online can the full features or the power of the Kasplex protocol truly be unleashed. Because in my view, the current 300 tps limit of go nodes is not quite sufficient.

BadSucker666 (Dr. Jason):

Yes, you also mentioned that the second phase of Kasplex’s plan will develop an on-chain DEX, and it features shared liquidity, which should all benefit from Kaspa’s inherent advantages.

5bb55b (Head of Kasplex):

Exactly, if the main chain were slow, we actually wouldn’t be able to do this.

Li Xianyu (Kaspa Chinese Community Moderator):

Someone asked: What problem does Kasplex solve? Is it useful for miners?

5bb55b (Head of Kasplex):

It’s quite simple. We can think of the blockchain ecosystem in two parts. First, you must be able to issue assets and enable their circulation. This is the foundation of what we call an ecosystem. Without these two conditions, there’s no point in talking about an ecosystem. Additionally, once the ecosystem develops, transaction fees will inevitably increase, which is definitely beneficial for miners. When the ecosystem thrives, miners naturally see more fees.

Li Xianyu (Kaspa Chinese Community Moderator):

I see a question asking if the white paper can be released within a week?

5bb55b (Head of Kasplex):

I’m not sure; I can’t answer that because it’s not yet finished, just a bit left. I think it should be about a week or two until it’s ready.

BadSucker666 (Dr. Jason):

Regarding fees, 5bb55b also mentioned that Kasplex has an interesting design. Kaspa’s current transaction fee pricing is divided into two parts: the first is a basic fee calculated based on the block’s mass, and the second is a priority fee added by users. The question is: which category do the fees mentioned by 5bb55b for the Kasplex protocol fall into?

5bb55b (Head of Kasplex):

They fall outside these two categories. You could consider it a third category, or say it’s defined by indexer rules. It is paid directly to the miners, essentially requiring an increase in transaction fees.

BadSucker666 (Dr. Jason):

So, this should require wallets supporting Kasplex to add an extra fee for protocol operations, right?

5bb55b (Head of Kasplex):

That’s right.

BadSucker666 (Dr. Jason):

This design should be a significant boon for miners, essentially opening up an additional source of income. How much extra income could there be?

5bb55b (Head of Kasplex):

I can’t say for sure right now. It depends on factors like how popular it becomes or how much it is used. It’s hard to say at this point.

BadSucker666 (Dr. Jason):

Kasplex should be Kaspa’s first official application. I’m looking forward to its performance! Someone asked if the indexer has any impact on the main chain’s efficiency?

5bb55b (Head of Kasplex):

There is no impact at all because the indexer pulls data directly from the node and does not write data.

Li Xianyu (Kaspa Chinese Community Moderator):

Before we see new questions, I’m quite interested to discuss with you two: when do you think 10 bps could be launched?

BadSucker666 (Dr. Jason):

I estimate about two to three months.

Li Xianyu (Kaspa Chinese Community Moderator):

The recently released Rust 0.14 version update primarily deals with the 1bps mainnet. Full deployment of Rust nodes on the mainnet should happen within a month.

BadSucker666 (Dr. Jason):

Right, Rust itself should be implemented within about a month. The 10bps test has been running for a long time, but because it involves a consensus change, optimistically, it would also take about two to three months.

5bb55b (Head of Kasplex):

I’d like to add that the Kasplex protocol will be compatible with both go version and rust version nodes. However, we will not maintain the go version nodes going forward; we will mainly consider rust nodes. I wanted to specifically mention this, as the go version nodes are about to be phased out.

5bb55b (Head of Kasplex):

I need to log off now, you guys continue.

Li Xianyu (Kaspa Chinese Community Moderator) and BadSucker666 (Dr. Jason):

Alright, thank you very much, 5bb55b!

BadSucker666 (Dr. Jason):

Let’s briefly summarize what 5bb55b discussed: since the first teaser on Twitter last December, by early May, we are close to seeing the first asset issuance standard from Kaspa. There have been community complaints about slow development, but there’s no need to worry. Kaspa’s key task is to polish the Base Layer, and the ecosystem projects will pick up speed very quickly. I hope Kaspa’s holders can be a little more patient.

Li Xianyu (Kaspa Chinese Community Moderator):

I understand your point. The Rust 1bps node is also about to be fully deployed, which is a significant improvement over the go nodes. Although it seems like there’s no change to users—still at 1bps—the upgrade is substantial for node operators and miners, with a lot of performance enhancements.

BadSucker666 (Dr. Jason):

Right, we’ve also talked about how Rust is essentially a complete overhaul of Kaspa’s infrastructure, which is a huge undertaking. If you look at Rust’s Source Code, you’ll see there’s a lot of work involved. Once the foundation with Rust is solidified, subsequent upgrades like 10bps and DK should proceed quite rapidly.

Li Xianyu (Kaspa Chinese Community Moderator):

Exactly. After the restructuring, piling on performance improvements actually happens quickly, not much code is needed anymore. Speaking of which, the 10bps test has been going on for about four or five months now, from January until now.

BadSucker666 (Dr. Jason):

Right, after Rust is complete, the theoretical proofs for DK are already done, what remains is converting them into engineering code. The rollout of the DK protocol should be faster than many expect.

Li Xianyu (Kaspa Chinese Community Moderator):

I see there are still quite a few questions asking about the launch date. Just now, 5bb55b mentioned that it’s currently impossible to provide an exact timeline. First, the full update timing for Rust nodes is uncertain, and the development of KRC-20 has several phases like internal and public testing. These are not easy to estimate accurately, so we just have to wait. First, we wait for their white paper to see the complete technical details, then their roadmap, which should be released simultaneously, and that will provide the timeline. Then we’ll know exactly when we can start using KRC-20.

I also see questions about which wallets support Kasplex. Firstly, Kasplex is an open-source protocol, and its APIs are public, so any wallet developer can make it compatible. It’s not decided by the KRC-20 project side but by the wallet developers. Although specific partnering wallets haven’t been disclosed, I personally speculate that OKX Wallet might be one. When it launches, we should have it available, at least by the time of the public test, there will definitely be supporting wallets available to explore.

BadSucker666 (Dr. Jason):

I see someone in the group asked about the relationship between smart contracts and inscriptions. I can explain more about the specific differences. Firstly, smart contracts are quite heavy because a smart contract’s transaction isn’t a regular transfer; it requires an external virtual machine on top of Kaspa’s main nodes to parse the OP Code, which is a substantial and complex engineering task. Of course, because it’s heavy, it can implement more complex logic, such as Turing-complete mechanisms. Once it’s Turing-complete, we can theoretically build any application on it. However, the way KRC-20 is issued differs significantly from smart contracts. It doesn’t require a virtual machine; it’s a lighter solution. As 5bb55b previously answered, both can perfectly coexist and complement each other. Like Bitcoin, which has some basic scripting language, such as the mechanism implemented by p2sh, essentially turns the transfer address into a script address, which can perform some simple processing logic on the chain, like multisig. Kaspa’s scripting design avoids many of the problems present in Bitcoin. Bitcoin’s Transaction development also went through several phases, first around 2017 with the SegWit upgrade that separated script processing logic into a distinct area. The second major upgrade was in 2021 with Taproot, primarily adding schnorr signatures. Bitcoin has four types of addresses, which are very inconvenient to use; Kaspa has already circumvented these issues. Actually, our discussion on issuing KRC-20 on the Kaspa mainnet is based on these premises.

Li Xianyu (Kaspa Chinese Community Moderator):

To summarize, Kasplex is an excellent protocol that won’t negatively impact the Kaspa mainnet. At the same time, Kasplex won’t compete with future smart contracts but will complement them. Additionally, Kasplex greatly benefits the current stage of ecosystem development and significantly enhances miners’ fee income. Once Kasplex develops, users will also be able to engage in more financial explorations, such as asset issuance or even play with Meme coins, etc. It’s a community product and ecosystem product that is very worth our community members’ anticipation. Its roadmap and white paper should be released soon, and everyone will be able to learn the detailed contents at that time.

BadSucker666 (Dr. Jason):

We have two new speakers who just joined us. The first is a developer from KasWare.

Shawn from KasWare:

Let me introduce myself. We are the developers behind the KasWare wallet. In December last year, we developed a wallet specifically for Kaspa, named KasWare. We started following Kaspa and invested in it two years ago. We have been closely monitoring Kaspa’s development and have seen its computing power and community grow. In December last year, we decided to start some projects for the Kaspa ecosystem. We noticed there was a lack of a plugin wallet for Kas, so we created one. Our wallet went into public beta on March 15 this year, and so far, we have released five updates. We’ve essentially included all the features that a wallet should have, both in terms of security and functionality. Additionally, we are in close collaboration with 5bb55b from Kasplex. We will support Kasplex as soon as the protocol is launched, including features like minting and deploying KRC-20.

BadSucker666 (Dr. Jason):

Can you share any details? How far have you integrated with Kasplex? Or is there a timeline for this?

Shawn from KasWare:

I can’t disclose specifics. Everything will depend on the updates from 5bb55b’s side.

BadSucker666 (Dr. Jason):

Okay, we can discuss more in our next session. What’s the next speaker’s question?

Questioner 2:

I saw someone asking in the comments if the indexer is decentralized. I’ve thought about it too. I want to ask: is the indexer protocol based on logical rules? If everyone follows these rules, can we achieve consistent results? Like the Chinese language, all Chinese people speak it, so everyone understands each other. Is the indexer similar to a dictionary or the script of the Chinese language itself? Is my understanding correct?

BadSucker666 (Dr. Jason):

You’ve understood it perfectly. Kasplex, as a protocol, defines a set of rules just like the language used for communication between people. These rules are based on data structures, which are the data we write on the Kas chain. Based on this data, we can use the indexer to read and then process it. The processing logic is implemented in code, similar to translating between Chinese and English. From the protocol’s perspective, it has deterministic rules. Decentralization is reflected in the fact that the code is open source; everyone can run and verify it.

(The End.)

The post Chinese Kaspa Community XSpace Ep13 – Kasplex appeared first on Kaspa.

The post Kaspa: Accelerating Beyond the Blockchain appeared first on Kaspa.

Crypto Forks

Do you ever wonder what a fork actually is in cryptocurrency? What is the difference between a hard and a soft fork, and why does it matter? Why do people make such a big deal over a fork in the road? Imagine standing at the edge of a vast, digital city, where the streets and intersections beneath your feet are the possible paths a network could travel. Now, envision this gridiron intersecting with these countless routes, turns, and junctions, each representing a potential direction for a network. Forks, in this context, are junctures where the community decides which path to take, shaping the future of the network.

This article was created based on insights from a thread posted by Shai Deshe Wyborski on X/Twitter.

https://x.com/DesheShai/status/1764610476749574498?s=20

Deciphering Forks

At its essence, a fork represents a divergence in the network, a moment of decision that can alter the network’s trajectory. But not all forks are created equal; they come in different forms, namely ‘soft’ and ‘hard,’ each with its own implications and outcomes.

The Subtlety of Soft Forks

Soft forks in crypto can be likened to software updates on your smartphone — they roll out new functionalities or corrections without interfering with your current applications or data. When applied to a network, a soft fork narrows the criteria for a valid block, ensuring the network can function smoothly without mandating an update from every node.

An excellent example of a soft fork is the Taproot update in Bitcoin, designed to augment privacy and efficiency without necessitating an upgrade from all participants in the network. Soft forks achieve this through backward-compatible changes, meaning the network remains operational even as some nodes operate on legacy versions. The Taproot enhancements, for instance, aimed at optimizing block space utilization and boosting privacy for intricate transactions, were deliberately engineered so that nodes yet to be updated could still validate and relay transactions. They would, however, not benefit from the new Taproot features. The uninterrupted functionality of the network following such an update is contingent upon a substantial majority of miners embracing the latest rules. This consensus among miners helps solidify the new rules as the standard, ensuring network coherence and sidestepping possible short-lived forks. The broad acceptance of the Taproot update by the mining sector and the broader user base exemplifies the communal collaboration pivotal to the triumph of soft fork integrations.

The Power of Hard Forks

On the other hand, hard forks are the equivalent of opting for a whole new operating system. They introduce changes that make new blocks incompatible with the old rules, necessitating a unanimous update across all nodes to prevent a split in the network. This is where the network can truly fork, creating parallel chains if not everyone agrees to the update. Hard forks can be deliberate, aiming to add significant new features or address fundamental issues, or they can be contentious, leading to a split in the community and the birth of a new cryptocurrency.

The creation of Ethereum Classic from Ethereum, following a dispute over how to handle the DAO hack, and the birth of Bitcoin Cash from Bitcoin due to disagreements over block size and Segwit2X are evidence of the profound impact hard forks can have. These events are major technical updates and can be pivotal moments for a community to reflect on deeper philosophical and strategic divides.

New Coins?

The emergence of new cryptocurrencies from hard forks is a phenomenon fueled by disagreement. When a significant portion of the community — miners, developers, or users — chooses not to adopt the new rules, the network can split into two distinct paths: one that follows the old rules and one that embarks on a new direction with the updated protocol. This is how new coins are born, carrying with them the legacy of their origin chain but diverging in vision and functionality.

The Effects of Forks

The implications of forks extend far beyond the technical, influencing everything from market dynamics to community trust and regulatory perspectives. They can lead to uncertainty and volatility in the short term as stakeholders adjust to the new status quo. However, they also embody the decentralized, democratic essence of crypto technology, where the community has the power to shape its future.

Navigating the Forked Roads

Regarding Kaspa’s evolutionary path, the emphasis is on proactive hard forks — thoughtful, anticipated, well-planned upgrades designed to enhance the network’s capabilities, security, and efficiency. These are not emergency measures or divisive decisions but more like the regular updates you’d expect from any evolving software system. Proactive hard forks are the project’s commitment to innovation and continuous improvement, ensuring that the network remains cutting-edge and can adapt to the ever-changing demands of decentralized finance.

The key to navigating these updates smoothly lies in the preparation and communication strategies employed by the Kaspa community, volunteers, and developers. The network ensures seamless transitions by keeping all stakeholders informed and engaged — miners, developers, and users alike. This collaborative approach minimizes disruptions and reinforces the community’s trust and action in the project’s direction.

Moreover, proactive hard forks offer an opportunity to introduce new features and optimizations that can significantly enhance the network’s performance and user experience. These can range from scalability improvements and increased transaction speeds to more robust security measures, all of which contribute to the overall health and competitiveness of Kaspa. i.e., Rust rewrite!

These planned hard forks should be viewed not with apprehension but as milestones in Kaspa’s ongoing development. They are clear indicators of a dynamic, forward-thinking project that is not content with the status quo but is constantly striving for excellence. This proactive stance on network upgrades is a positive signal for the community and users alike, showcasing Kaspa’s dedication to enabling a resilient, innovative, and future-proof ecosystem.

Tip: Always stay informed and actively participate in your crypto community’s discussions to better understand and navigate the impacts of forks and the network’s future.

KASPA | KASPA WIKI | MEDIUM | TELETYPE | DISCORD | TELEGRAM

TWITTER | GITHUB | N. R. Crowningshield | Bubblegum Lightning

The post On Crypto Forks appeared first on Kaspa.

Pushing Boundaries… Again!

On the evening of January 7th, at 8 PM UTC, another pivotal chapter in the Kaspa saga will be written in code and history with the second unveiling of Testnet 11 (TN 11). This public release is the second expedition into the new Rust codebase that brings the promise of the impossible 10 blocks per second (10 BPS) on a proof-of-work (PoW) network. The digital experiment provides an arena where developers and enthusiasts will come together to push the envelope, exploring the dynamics of the PHANTOM GHOSTDAG protocol live on the Rust programming language.

Testnet 11 is far more than a proving ground; it’s a digital recreation of the real world. Focused on simulating and stress-testing a miniature version of an entire ecosystem, a world’s worth of transactions, all anxious to settle instantly to buy their favorite snacks. Its evolution on fast-forward, where the protocol endures rigorous trials, loads of simulated throughput, real-world mining and use, all while ensuring efficiency and security against any real-world scenario.

Rusty Kaspa

Rewriting the Kaspa programming language from Go to Rust is an essential development to enhance performance and manage the complexities of the BlockDAG. This transition enables the groundbreaking achievement of 10 BPS, which allows for greater scalability and throughput. By increasing the BPS, the potential transactions per second go upwards to 3,000 TPS, as demonstrated in the highly successful first public release of TN11. The Rust programming language offers advantages such as higher efficiency and improved performance, memory safety, interoperability, error handling, and a growing crypto ecosystem and developer community.

Testnet 11 Updates

Since the first public Testnet 11 captivated the crypto world, several enhancements have been implemented to optimize network efficiency and performance. Improving high BPS Peer-to-Peer (P2P) communication, focusing on fine-tuning and orphan revalidation, is crucial for seamless network functionality under high transaction volumes.

Storage efficiency has also advanced with updates addressing the issue of quadratic writes in high BPS contexts, refining the network’s data processing and storage capabilities. These updates, along with smarter caching through dynamic data tracking and enhancements like parallel processing for block submissions, signify a considerable leap forward for Kaspa, a display of the developers’ ingenuity and insights gathered from the initial experiment. Refer to the Release Notes at the bottom of this article for a comprehensive overview of the updates.

Participating in Testnet 11

Participating in Testnet 11 is straightforward, primarily focusing on software requirements. The essential software needed is Rusty Kaspa, which acts as a portal, seamlessly connecting your system to the network. This enables synchronization with other nodes on TN 11. You have the option to run the node as it is, which is a straightforward way to participate. However, Rusty Kaspa also opens the door to additional testing features if you want to explore further.

CPU mining is the exclusive method for mining in Testnet 11, and it’s a crucial aspect of the process. By participating in CPU mining, you contribute to the TN 11’s computational strength. The advantage here is the simplicity and accessibility: you don’t need any specialized mining software or hardware to get involved. TN 11 comes equipped with its own CPU miner, making it easy for anyone to participate in this capacity. Although transaction simulation using the Rothschild tool is optional, if you decide to mine on TN 11, it’s vital to use CPU mining. This method is the designated approach for mining in the network. This simplifies and democratizes participation, enabling a broader range of users to contribute effectively and interact with the network’s features.

For hardware, a setup with at least 16GB of RAM, an 8-core CPU, and a 128GB SSD drive is recommended to handle the demands of the TN 11 environment efficiently.

Testnet 11 Instructions

Need support? Have feedback?

The Kaspa Discord #testnet channel is your go-to for troubleshooting and discussion. At the same time, #rust-rewrite offers a greater understanding of Rusty Kaspa development and updates.

Redefining the Proof-of-Work Consensus

Testnet 11’s performance is key to shaping Kaspa’s future, especially the shift to 10 BPS speeds on the mainnet. The data from these tests are necessary to tackle any needed optimizations and prepare for the mainnet to operate on Rustlang.

For a deep dive into participating and understanding the Rust rewrite, check out the Rusty Kaspa GitHub page. Remember, TN 11 is an experimental zone — expect some instability as part of the process.

The release of Testnet 11 marks a significant stride in cryptocurrency innovation, offering a unique platform for testing and fortifying the developmental foundation of the Kaspa PHANTOM GHOSTDAG protocol. It’s a critical step in the quest to push the boundaries and achieve the ultimate goal of 100 BPS.

Tip: It’s important to remember that Testnet 11 is a testing environment. It may face instability and occasional downtime due to experimentation processes. Nothing to worry about, and it’s anticipated.

Release Notes

Testnet 11 Updates

Improvement to high BPS P2P:

PRs:

• Fine-tuning — https://github.com/kaspanet/rusty-kaspa/pull/356
• Orphan revalidation — https://github.com/kaspanet/rusty-kaspa/pull/359
• Perfects the P2P at high BPS. Also fixes the long-standing IBD loop.

Improvements to storage efficiency:

PRs:

• Reachability refactor: https://github.com/kaspanet/rusty-kaspa/pull/347
• Block child relation refactor: https://github.com/kaspanet/rusty-kaspa/pull/325
• These PRs together eliminate quadratic writes in higher BPS to their respective storages, allowing the node to store block reachability and child relation data efficiently.

Improvement to caching:

PRs:

• https://github.com/kaspanet/rusty-kaspa/pull/351
• Caches for dynamic data now track that size and adjust accordingly.
• This should prevent Out-of-Memory issues — the caches are limited to what is needed for the node to operate smoothly.

Other Testnet 11 Changes

• https://github.com/kaspanet/rusty-kaspa/pull/357 — Parallel submit block processing — Submitting blocks can fill the message queue in higher bps, leading to serialization of processing (defeating the purpose of higher bps). This fixes that.
• https://github.com/kaspanet/rusty-kaspa/pull/320 — Various initial fixes from issues found in the internal TN11 experiment
• https://github.com/kaspanet/rusty-kaspa/pull/317 — Clear block template only when it’s expired.
• https://github.com/kaspanet/rusty-kaspa/pull/311 — Add request and response ID to every p2p message and route messages accordingly.
• https://github.com/kaspanet/rusty-kaspa/pull/356/files — Fine-tuning parameters.

Other non-TN11 Rusty Kaspa Update

Improvement to node initialization and overall health:

PRs:

• https://github.com/kaspanet/rusty-kaspa/pull/333
• https://github.com/kaspanet/rusty-kaspa/pull/345
• These initialize the FD limits so that the node will have the resources it needs to run.

Wallet and Metrics Overhaul

PRs:

• https://github.com/kaspanet/rusty-kaspa/pull/360
• This is the solid foundation on which the new rust-based KNG wallet is based.

Improvements to node reachability via UPnP

PRs:

• https://github.com/kaspanet/rusty-kaspa/pull/300
• https://github.com/kaspanet/rusty-kaspa/pull/288
• These changes introduce UPnP, which allows more nodes to become publicly connectable. The more public nodes there are in the network, the better the interconnectivity of the network becomes.

Other changes

Covered by the release notes in https://github.com/kaspanet/rusty-kaspa/releases/tag/v0.13.0

KASPA | KASPA WIKI | MEDIUM | TELETYPE | DISCORD | TELEGRAM

TWITTER | REDDIT | GITHUB | EXPLORER | Bubblegum Lightning

The post Kaspa on Rust: Evolving Testnet 11 appeared first on Kaspa.

New Mempool Implementation Manages Thousands of Pending Transactions

Rusty Kaspa Mempool Update

Kaspa recently unveiled another significant advancement in the performance of their mempool, a term referring to the temporary holding space for unconfirmed transactions. The new mempool design can now manage a high-frequency 10-BPS network, even when saturated with hundreds of thousands of pending transactions.

Behind this achievement stands Michael Sutton at the helm and documenting the process on Twitter/X, joined by the Rust powerlifter Tiram_88.

Some months back, Kaspa halted its eleventh testnet, TN11. This decision was primarily made to refine everything associated with the pathways of the mempool’s operations. Before this intervention, the focus was mainly on refining their consensus validation engine. This engine, created with parallel processing in mind, was tested and proved capable of handling approximately 32 BPS. However, challenges arose when attention shifted to the mempool. Its initial design was straightforward and needed to be refined to manage heavy loads, revealing bottlenecks that hindered performance.

Mempool Bottleneck

This graph, Figure 1, illustrates the challenges of the previous mempool system under constant pressure. It showed significant strain when subjected to an influx of transactions more than a 10-BPS BlockDAG could efficiently manage. The system nearly halted at one point, especially between the 60 to 80-second marks, even though it was handling a mere 35,000 transactions. Two metrics stood out in this figure. The left demonstrates the operation time, while the right showcased the real-time mempool size. Both metrics reflected that the Build Block Template (BBT) and the block submission times were increasing at a high rate in correlation with the mempool size. This indicated the need for internal mempool algorithm optimization.

Optimization objectives

— The system needed to quickly build blocks, which is crucial for the network’s responsiveness.

— Once a transaction was confirmed, it needed to be removed from the mempool promptly, ensuring a smooth operational flow.

— Maintain a consistent rate at which the new, unconfirmed transactions are accepted, regardless of the mempool’s load.

Results

The mempool then underwent a transformation. Large operations were fragmented into smaller, more manageable tasks, allowing many to run concurrently. Additionally, the internal algorithms of the mempool received significant overhauls for improved efficiency.

The results of these interventions were nothing short of impressive. Michael Sutton referred to Figures 2 and 3 to underscore the improvements. In tests, they attempted to send a staggering 1.4 million transactions to a node to prove that until the mempool reaches a stable size of 600 thousand transactions. Over 600 thousand, the transaction submissions will alternate pausing and resuming to maintain. Figure 2 showed that BBT times were around 25 milliseconds, while block submissions averaged 150 milliseconds. Simultaneously, Figure 3 highlights the transaction processing speed of over 2,000 transactions every second. Most notably, these figures remained stable, even with a considerable load on the mempool, indicating that the node performed seamlessly.

The Nutshell

Kaspa’s advancements signal a more resilient, efficient, and adaptable system. It’s designed to manage a significant transactional load without compromising performance, marking a pivotal moment for Kaspa’s breakthrough technological journey.

The days of frustrating delays, throughput limitations, and lengthy transaction times are poised to be things of the past. With a keen focus on quicker transactions, the revamped system efficiently processes tasks, even amidst high transaction volumes, ensuring unparalleled reliability.

Twitter Kaspa Update

Tip: With a potential to manage thousands of transactions seamlessly, Kaspa’s 10-BPS mempool is the future of practical everyday commerce.

KASPA | KASPA WIKI | MEDIUM | TELETYPE | DISCORD | TELEGRAM

TWITTER | REDDIT | GITHUB | EXPLORER | Bubblegum Lightning

The post A Kaspa Performance Update appeared first on Kaspa.

NOWCommerce with Kaspa

The primary use of Kaspa and the original use case of cryptocurrency, in general, is stateless money and P2P transactions of decentralized money. The journey starts with commerce, and this is where NOWPayments comes into the picture. As a significant player in the crypto payment gateway space, NOWPayments is making waves with its recent integration with Kaspa (KAS), furthering the practical use and decentralization mission.

NOWPayments

NOWPayments is a crypto payment gateway that stands out for its tailored solutions and accessibility. By integrating Kaspa, NOWPayments adds a new dimension to its offerings, fostering the broader acceptance of decentralized money.

Focusing on industries like gaming, NFT marketplaces, and e-commerce platforms, NOWPayments provides customized API solutions that seamlessly integrate crypto payments. This commitment to personalization ensures that various sectors can embrace crypto practically and realistically with the ability to fit each business model.

Integration lies at the heart of NOWPayments. With its user-friendly platform, businesses can effortlessly integrate with platforms like Shopify, accepting crypto payments as part of their regular operations. This ease of integration bridges the gap between traditional and digital currencies, embodying the original concept of stateless money.

While maintaining a solid focus on crypto payments, NOWPayments offers Fiat conversion to onboard more traditional users into the digital currency. The system’s lightning-fast speeds ensure that payments are quickly recognized on the blockchain, keeping transactions smooth and efficient.

While maintaining a solid focus on crypto payments, NOWPayments offers Fiat conversion to onboard more traditional users into the digital currency. With the integration of Kaspa, merchants can receive KAS and instantly exchange it for a stablecoin. This process allows them to enjoy the security, speed, and minimal fees of Kaspa while avoiding the potential volatility often associated with cryptocurrencies. The system’s lightning-fast speeds ensure that payments are quickly recognized on the BlockDAG and updated for both the user and the merchant, keeping transactions smooth and efficient.

This added functionality illustrates NOWPayments’ commitment to combining the innovative aspects of cryptocurrency with the stability and familiarity of traditional financial systems. It builds a bridge between two worlds, ensuring that businesses can capitalize on the unique benefits of Kaspa without having to navigate the often complex landscape of digital currency volatility. Whether you are a seasoned crypto enthusiast or a business exploring digital currencies for the first time, NOWPayments’ seamless integration of Kaspa offers an accessible and efficient solution.

Become an Affiliate get Rewarded for KAS Adoption!

NOWPayments isn’t just about providing innovative payment solutions; it’s also about building a community and incentivizing the growth of the Kaspa ecosystem. As part of this commitment, NOWPayments offers an attractive affiliate program that enables individuals and businesses to earn rewards by promoting connections between merchants and NOWPayments.

Here’s how it works:

1. Register an Affiliate Account: By simply registering an affiliate account, you can start earning money by building ties between merchants and NOWPayments.
2. Share an Affiliate Link: Once registered, share your unique affiliate link to engage potential partners.
3. Earn a Percentage: Get a percentage from every transaction of your referred partners for an entire year! Specifically, the reward amount is 25% of NOWPayments’ service fee for each transaction.
4. Spread the Word to your Favorite Merchants to Accept Kaspa!

NOWPayments

Disclaimer: The Affiliate Program extends beyond merchants. The NOWPayments links in this post are my Affiliate links for demonstration. Share your own link and use others’ to sign up, promoting Kaspa adoption!

KASPA | KASPA WIKI | MEDIUM | TELETYPE | DISCORD | TELEGRAM

TWITTER | REDDIT | GITHUB | EXPLORER | Bubblegum Lightning

The post Kaspa Integrated on NOWPayments appeared first on Kaspa.

The post Kaspa Community AMA with Guest @realKateL from ChangeNOW & NOWPayments appeared first on Kaspa.