The post Getting up to Speed on Kaspa appeared first on Kaspa.

First and foremost I wanted to thank you all for joining and forming this community, for the interest, excitement, and involvement around the project. Seeing my PhD obsession — POW DAG consensus — realize itself into a live network and a spontaneous community is thrilling yet humbling. Thank you, Todah!

I’m definitely going to start valuing members-count over citation-count, so please bring more crypto friends to the party!

Every few years a new fair-launched POW cryptocurrency captures the excitement of the community — Litecoin, Monero, Grin, and now Kaspa. May the force be with us.

Since we didn’t anticipate this rapid growth, I didn’t prepare accessible answers to several FAQs. I hope to write a longer post about all this in the coming days, but for now here are some answers:

1. Monetary policy will be deflationary. Halving will be more aggressive than Bitcoin’s since market conditions are different (order-of-magnitude faster market discovery). When the deflationary scheduling will be activated, and what would be the initial block reward (compared to the current avg of 500) — TBD. We will try to seal this next week or so. These numbers will imply the finite cap on supply. BTW we should rebase the term Kaspa to refer to today’s 1000 Kaspa, say; the current representation feels not so scarce 🙂
2. Our proof-of-work is a Kaspa variant of heavy-hash, let’s call it k-heavy-hash. My goal here was to create a CapEx heavy POW function, since I believe this concept is both energy-efficient and provides more miner-commitment (stronger than ASIC since less OpEx burnt). Whether k-heavy-hash is actually CapEx heavy, and whether a different POW function will better serve this goal for Kaspa — is a question I’m open to discuss.
3. The project is maintained by a few devs, all of which have other full time dealings, and some of which are funded by DAGlabs (but totally self managed). In particular, there’s no company or entity behind the project that is responsible for your wallet, full node, funds, miners. We are here during our spare time. I, for one, am a full time postdoc at Harvard university, and while this project is my PhD baby, I am at the same time dedicated to my postdoc baby. So this is a purely community project, please take that into consideration. What can you do to help? Arrange for more dev-power to learn the codebase and join the efforts; DAGlabs can potentially fund additional devs, as long as they have the ability to manage themselves, open issues, fix bugs, manage PRs, etc.
4. Roadmap. There is no official roadmap as there’s no organized development. I can write down what devs should be working on IMO, post bug fixing and version updates (HFs). In short, IMO priorities should be accelerating gradually to 10 blocks per second, then implementing an amazing upgrade to the consensus protocol, pending theoretical research results of Michael Sutton. In parallel, if someone can promote a privacy gadget (e.g., bulletproofs) and implementation for Kaspa that would definitely leap us forward.
5. Next week there will be a hard fork (HF) in order to fix a bug and decrease header size. Tune in on this, especially if you are running a mining full node. A few weeks later there will be a HF to embed said monetary policy.
6. Will we list the coin on exchanges? There is no “we”, there’s “you”. And I suggest waiting for the community to grow more organically before bringing retail.
7. When is it recommended to stress test for utxo throughput? You are free to stress test as you wish. However, note that even if bugs are discovered, some time will pass before the devs can make themselves available to fix them. Therefore, I suppose better wait for the current system to prove itself stable for more than two weeks, say.
8. What about block explorer? I believe next week devs will deploy one.
9. Feel free to follow me here or on Twitter https://twitter.com/hashdag where I hope to post more Kaspa related material in the coming weeks.

The post Kaspa launch plan (responding to reality) – Pt-2 appeared first on Kaspa.

• launch Kaspa in gamenet mode, a research oriented experimental network
• inject deliberate fragility into Kaspa launch via random semi-scarce monetary policy
• construct battlefield for reward-based and MEV-based reorgs
• as community matures and hashrate grows, go full scarcity mode, transition from game- to main- net mode, rendering early (gamenet) stage miners profitable in retrospect
• gamenet 2.0 requires developing Ethereum bridge to simulate and practice MEV-reorgs, in order to test and demonstrate DAG consensus’ antifragility

Why Kaspa shouldn’t launch as an ordinary cryptocurrency

[L1, POW, lack of EVM]

There seems to be little room now for a new L1, especially one powered by PoW such as Kaspa. The market has matured, and with it the scope of attacks and manipulations has expanded from direct attacks on block ordering (eg double spends via reorgs, liveness attacks) to attacks that regard txn content — typically in the zero-to-one-confirmations phase — by miners or bots (aka flashbots). Moreover, Kaspa lacks as of now EVM support, rendering it significantly less relevant to the current market.

Gamenet: A proposal to launch Kaspa in a novel experimental mode

Kaspa may be launched as a research-oriented consensus engine that is focused on experimentation, novel testing of dynamics, and a vibrant battlefield for real world cryptoeconomics attacks. I call it gamenet mode.

Cryptoeconomics phase 1

[CPU/GPU mining, uncertain scarcity, low hashrate and security, non-commercializable]

The platform should be CPU/GPU-mineable, to facilitate the base activity; I believe Ethash is a neutral candidate that fits our needs. However, its token should be deliberately unfit for commercialization, in order to penetrate hardcore communities, individuals, and zones that refrain from cooperating with non-BTC or non-ETH tokens. Accordingly, the token’s supply should challenge the ordinary notion of scarcity, and should be unfit for exchange listing. This implies that the platform will obtain low hashrate and low security, at the initial stages.

Gamenet activity

[battle-field, simulation, real world game, selfish mining, reorgs, MEV]

The theme of gamenet’s activity can be thought of as a continuous hackathon over a live network which serves as a battle-test field for simulating real world attacks, manipulations, and dynamics of a multi-player network. The block rewards will incentivize occasional reorg/selfish-mining attacks by strategic and sophisticated miners of the gamenet, whereas transactions in the network will implicitly or directly reflect MEV exploits from real world DeFi systems such as Ethereum.

Community

[R&D groups and individuals, testbed for innovation, recognition by broad crypto community]

The goal is to attract research and dev groups (e.g., flashbots fans) to play, compete and/or collude over the live system, and to extract insights on the real-world dynamics of other live systems such as Ethereum. Further, commercial L2 projects that propose solutions to certain exploits, such as using cryptographic primitives for MEV, can implement those over Kaspa gamenet and prove the robustness of their solution, while others may attempt to refute it. I hope Kaspa will become a center of a vibrant R&D community, and that the general community will look to Kaspa gamenet as a credible source of insights regarding cryptoeconomic dynamics in the wild.

An example for the community’s interest around the topic may be found in this recent summit http://reorg.wtf/

Cryptoeconomics phase 2

[monetary policy solidification, recover scarcity, compensate early community]

As the community and the platform matures, we will want to transition to a solid monetary policy, regulate the supply, and trade over exchanges. To this end, we may set an automatic trigger in consensus that will eliminate the randomness in the monetary policy, and the uncertainty of the supply, once a certain hashrate is reached. This will automatically compensate early participants — the early miners of the network — by rendering the mined tokens scarce in retrospect. See below for specifics. See https://fc21.ifca.ai/papers/222.pdf by Lucianna Kiffer for a related design.

Kaspa development and support

[community+product management, further development and support]

As a continuous real-world hackathon, Kaspa gamenet can significantly enjoy some product and community management, conveying and demonstrating to the community the rules of the game and example dynamics. Community members are welcome to take the lead on these fronts.

On the development side, and closer to the backend, explicit MEV activity can be simulated via a bridge from Ethereum. While not necessary for gamenet, I believe gamenet+MEV will make the platform much more attractive a battle-field.

Individuals capable and willing to take upon themselves some of these efforts, and who require funding, may DM me.

Timeline

[Kaspad ready mid October, Kaspa launch end of October, full gamenet activity TBD]

Kaspad — the core consensus component of Kaspa — will be production ready (though untested) by mid October. The remaining features are (1) implementation of the monetary policy described below, (2) plugging in the chosen PoW function.

The execution of components that enhance gamenet activity depends on community engagement.

Monetary policy and block rewards

Requirements

The block reward should incorporate randomness so as to:

1. Test selfish mining and reorg attacks,
2. Introduce uncertainty regarding the supply,
3. Incentivize extending the main chain, 95% of the time (say),
4. Incentivize forking the chain when the reward — or the MEV opportunity — is exceptionally high.

Concrete proposal

Have each block mint a random amount of Kaspa, where the randomness is a function of the last $M$ blocks. The result of the randomness, the “sampling”, should depend on the block’s hash, to ensure that it cannot be gamed. The randomness should not be a function of the previous block only ($M=1$) because that will lend itself to frequent forking attacks. At the same time, it should be responsive to recent blocks, to ensure a sufficient degree of uncertainty with respect to the supply (so $M=10¹²$ won’t do, as well). I propose $M=~100$ blocks.

Formal description

Given a DAG $G$, GHOSTDAG outputs a chain $C(G) \subseteq G$. For each block $B ∈ G$, let $merging(B)$ be the earliest block in $C(G)$ that contains $B$ in its past. For each block $B ∈ G$, $B.selectedParent$ is the tip of the chain $C(past(B))$. For each block $B ∈ G$, $mergeSet(B,G)$ is defined as $past(B)∖ past(B.selectedParent)$ if $B$ is in $C(G)$, and the emptyset otherwise.

The reward of blocks in G, $rew(*)$, is defined by:

• $rew(genesis) = const_1$
• $rew(B) = const_2*avg_{D \in prvs M blocks of B}rew(D)*4^x + const_3*sum_{D\in mergeSet(B)}(rew(D))$

where $x$ is a random variable drawn from the normal distribution (mean 0, std 1), and which is uncontrollable by the miner (it is the result of the block hash). $const_1=1$, and $0<const_2,const_3<1$ should be in the order of $0.9$ and $0.1$ respectively; $M$ should be in the order of 100 as mentioned.

Hashrate trigger

Once the network reaches a meaningful hashrate, one that corresponds to operational expenses of $I=250k USD$ per week (say), the randomness should be eliminated, and then each block should mine a block reward of $rew(B) = const_3$ (const_3=1, say). This could be triggered automatically in consensus and requires no soft/hardfork.

Finality parameter

In phase 1, due to the expected low security, the finality parameter of the system should probably be set to be in the order of minutes rather than hours. In case of netsplits, the conflict should be resolved manually, which is a legitimate practice in a non-mainnet platform.

The post Kaspa launch plan (proposal) Pt-1 appeared first on Kaspa.