Snark: Tokenomics
Token Purpose
The key aspect of a token is to secure the network.
A tokens purpose is to reward good behavior, and punish malicious behavior.
At the core design of a blockchain, the token model is easy. Reward for hosting nodes and providing useful work. In a staking model this is usually done via token dilution.
The lack of blocks, create the lack of block rewards. Instead, for any given epoch, fees are accumulated and distributed proportional to stake of the epoch.
Token Minimum
There is an inverse correlation to reward and fees. As fees decrease, reward should increase, as fees increase, rewards should decrease. No system yet models this dynamic relationship.
Ethereum, as an example, has to hard fork with every block reward decrease. Instead this introduces the concept of a minimum reward threshold.
We consider a reward mechanism of 10 ZK per epoch. A 10 ZK minimum is proportionally rewarded for each epoch, should fees accumulate in access of 10 ZK, the fees are instead used and no new ZK is minted.
This liquid relationship between minimum reward and fees allows the system to reach an equilibrium of self sustainability.
Rewarding Positive Behavior
Positive qualities;
- Accept pending transactions
- Validate transactions
- Finalize transactions
Negative qualities;
- Dismiss or Deny transactions
- Create false transactions
- Spam transactions
- Double spend transactions
Positive behavior is passive. By virtue of acting as a passive actor the node promotes positive behavior.
We previously discussed the concept of transaction finalization and broadcast limiting. These two qualities also inherently create a defensive mechanism.
Dismiss or Deny transactions
Positive nodes are inherently scored by their participation in transaction finalization. Positive nodes thus create an inherent reputation score. As a node refuses to finalize transactions their reputation score deviates further and further from the median. If this score falls below the median stake is revoked and participation is no longer counted.
False transactions
Separation of Node and Actor become important. Malicious transactions (and double spends) originate from an account. The concept of account level denial needs to be incorporated into a positive system. Quite a few systems introduce the idea of account limiting, soft thresholds to stop spam behavior. The concern is this excludes enterprise level interaction, this speaks more towards spam transactions than false transactions.
Spam transactions
This is a subject that has been dealt with extensively and is primarily augmented via fees. Fee’s can make a system prohibitively expensive to use. Fixed fees can be introduced via Oracles, although Oracles can lead to other malicious attack vectors.
Dynamic fees based on nonce are proposed. Increased nonce allows for decreased fees. This rewards consistent positive behavior
Double spend transactions
This has been one of our favourite areas of study. Specifically since a double spend is not a falsified transactions. The objective is to introduce two similar transactions into a system to create a deadlock.
Given the absence of blocks, it is theoretically possible that 2 transactions could reach similar finality and thus lead to a forked state. There is no mechanism to resolve this unless a judge or other intermediary is consulted. While this probability is finite it does exist.
Law of probability dictate that if something can occur, it eventually will occur.
Addendum: Discussion of Finite probabilities
Forked dead lock state
As described above.
Account collision
“An Ethereum address is 160 bits, so there are 1.46 * 1046 possible addresses. Generating 1 trillion unique addresses would cover 1.46 * 10–34 of the possible address space.”
“To put 1046 in perspective, the volume of the Sun is only about 1045 cubic micrometers. You could have ten addresses for each cubic micrometer in the Sun.”
Does the possibility of being finite extend we do not have to cater for this issue?
Hash collision
As above but for transaction hash space.
