Yonatan Sompolinsky

• 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.