Perpetual Auction Currency - Part 1
This topic explains a new approach to setting the farming reward. Nodes in a section all bid on what they estimate is a reasonable reward per GET. The reward amount is set from those bids. The trick is how to use the bids to correctly establish a meaningful reward amount in a way that cannot be easily manipulated.
This is radically different to prior ideas which were all based around predefining an algorithm using measured parameters.
The network is currently intended to algorithmically calculate the reward based on the relative availability or scarcity of resources; as more storage becomes available the reward decreases, and as storage becomes scarce the reward increases.
However, this idea fails to incorporate other value derived from network activity. This varies widely as a result of many factors other than relative scarcity of storage.
Using storage as the primary economic measure unnecessarily combines unrelated friction points and gives undesired price discovery and economic results. Too much responsibility is packed together, separate concerns entangled.
Our radical deviation from existing ideas has been a very long process. There’s been a lot of research and justification to arrive at perpetual auction currency (PAC), too much research to include in this initial outline of the idea. The details of that research will be presented in the following post.
Nodes within a section can bid for how much reward should be given for each GET completed. A list of the latest bid for each node in the section is kept by the elders. Any vault may update their bid at any time. Whenever the BLS key changes (ie the elders change), the new BLS key is sent to neighbours and must also include the median of all bids at that time.
When the section receives a new BLS key from a neighbour (and thus also a new neighbour median bid), they use the new neighbour bid (NB) to calculate a new reward amount for each node. The difference between the NB and each node bid is used to set the reward amount for each node (see example below).
Nodes whose bid is close to the neighbour bid get the most reward per GET. Nodes whose bid is far from the neighbour bid get only a small amount of reward per GET. Since nodes cannot know the next NB in advance there is a tension that requires nodes to bid their true desired reward without bidding too far from the expected neighbour bid.
Incentives and considerations
Bidding higher than NB
- chance to increase reward
- don’t bid too much more or penalty for being far away from NB could be painful
- don’t bid too much more or it becomes attractive for competitors to join the network
- don’t bid too much more or inefficient operators may become viable and the network will become slower
Bidding exactly/close to NB
- simple strategy
- best chance of predictable income
- stability in economy hopefully brings stability to other aspects such as client usage etc.
Bidding lower than NB
- chance to reduce reward and make inefficient competitors nonviable
- helps network discover true value, personal sacrifice for the public good
- slows new coin creation so existing farmed coins are more scarce/valuable
- don’t bid too much lower or penalty for being far away from NB could be painful
In between exchange of BLS key updates, every vault in a section includes their bid for farming reward as they respond to GET requests. The latest value is kept at Elders. When the section has a BLS key update to send to its neighbours, they include the median value of the current bids from the section. The receiving sections use this value for farming reward, until they get a new BLS key update. We can call this neighbour bid (NB). There is only ever one NB used in a section, and it’s the one included in the most recent BLS key update received from a neighbour. It means it will constantly be updated, from random neighbour section.
There is one more thing that enables this to work securely: In every group, NB is dealt out among the nodes in the section, according to each of their last bids before this NB was received. The closer to the NB the bid was, the higher the reward.
At any given time, it is unknown to bidders when the next BLS key update is. As a result of this, every bid made will have to estimate what everyone else thinks everyone else thinks.
This keeps the bidding pinned to each other’s common knowledge of the value, as there is no advantage in deviating from this strategy. Rather, there is only disadvantage in such deviations.
Due to these characteristics, this system should be very hard to game. Everyone is motivated to guess on what the others would most likely guess. The best information people have on that is (and becomes) the actual market value.
Nodes default to some predefined strategy (or set of strategies), which is called passive bidding. Initially it’s proposed that nodes who bid passively will use the last NB for their current bid.
Nodes that try to measure the true market value can set a bid according to their own strategy and are called active bidders. They hope to use any available information to bid closer to the next NB and therefore get a better reward than if they were passive bidders.
Nodes may have some visibility of the current bids, which gives everyone the ability to adjust their bids in real time between NB events, and thus more likely to have an accurate bid at the next NB event. This should keep the reward more responsive to the market valuation. There’s constant information exchange - within the section at least, perhaps even on a larger scale too.
Those who get punished are most likely the active bidders who repeatedly do a bad job or are unlucky.
The NB is occasionally, at a low rate (for example 5% of NB:s), set to the average bid (NBa) of a section instead of the median (NBm). This is necessary as to always keep the reward responsive to the collective valuation, even when the ratio of active bidders is low. Without it, the median bid of a section, with 50% or more passive bidders, would always be the previous NB, which in turn also was the previous NB - i.e. there would be no bid mobility.
When occasionally sampling the average, the system allows for any deviations to impact the price discovery. The randomness and low rate ensures that this phenomenon is bounded and managed within the limits necessary to maintain the integrity of the system.
NBa is calculated using floor when NBa is below the current NB, and ceiling when NBa is above the current NB. This maintains bid mobility even with as few as one active bidder in a section.
For example, bids of (100, 100, 100, 100, … , 100, 99) using NBm would be 100, using NBa (rounding) would be 100, but using NBa (floor) would be 99, so it potentially requires only one bid to vary for the NB to move, rather than 50% of bids if using median or average-with-rounding.
NBa allows the bid to move higher or lower equally easily without a bias toward having greater or lesser reward over time.
As an additional protective measure, bids are always limited to a maximum absolute deviation of 1% from the current NB. If bids are allowed to be extreme then the bidder may be willing to accept the short term loss of reward for the long term benefit of greatly changing the reward in NBa events.
The reward may be distributed between the nodes in various ways.
The main way to distribute rewards is to give more reward to nodes with a bid close to the new NB and less to those far away. This encourages vaults to negotiate the tension between the bid that best represents their true costs, the bid that best represents their desired profit, and the bid that best reflects the current market value. Their maximum reward comes by aligning their costs and profits exactly to the current market value.
Other ways of adjusting the reward may be:
- Reward bids lower than the NB slightly more than bids higher than the NB, to provoke a gradual bias toward lessening of reward over time.
- Weight by age, giving more reward to older nodes.
- Give more reward to the fastest nodes.
- Scale the reward (and storecost) depending on the size of the chunk so the economics become per byte rather than per chunk.
Proof of storage may be used to give more reward to the nodes that have the most storage so are therefore the most futureproof.
The exact way to apply weighting is yet to be decided, but the major incentives and protections must come from proximity to the NB.
Nodes bid within their section for the reward they want (occasionally updating their value if needed). In this example, the current list of bids held by the elders is:
(64437, 64451, 64467, 64476, 64503, 64512, 64534, 64551)
At this point of the bidding the section receives a new BLS key from a neighbour. The new BLS key comes with additional data for the median bid in that neighbour section, which is 64500.
The distribution of reward for each vault is updated based on distance between the current bids and the new neighbour bid.
Bid Bid Distance position to NB #1 64503 +3 #2 64512 +12 #3 64476 -24 #4 64467 -33 #5 64534 +34 #6 64451 -49 #7 64551 +51 #8 64437 -63
The closest bid is +3 away from NB so gets the most reward
The next closest bid is +12 away from NB so gets slightly less reward
This decrease in reward continues until the furthest away bid of -63 gets the least reward.
Total percentages of reward then becomes as follows (exact way to calculate this breakdown is yet to be decided, this one is based on the sum of the differences, if you have ideas for this it would be great to hear them, we’ve tried a lot but not settled on any one in particular)
Bid Tot. Pos. % #1 14.2 #2 13.6 #3 13.0 #4 12.5 #5 12.5 #6 11.7 #7 11.6 #8 10.9
With an example NB of 64500, all GETs are rewarded the following amount per GET until a new NB arrives:
Bid Amount position received per GET #1. 9159 #2. 8771 #3 8385 #4 8063 #5 8063 #6 7547 #7 7482 #8 7030
Risks / Considerations
One concern is the bids might be too sticky. If the penalty of putting out a true-but-very-different bid is too risky then bids won’t easily change. It’s expected the NBa mechanism will be enough to counteract sticky bids but the question is still subject to further discussion and consideration.
The PA seems pretty robust against collusion since it’s very easy to defect from a colluding group and this would be very costly to those who don’t defect, so the best strategy is simply don’t collude in the first place.
One thing to consider would be if the current reward is 100, it’s not fair to allow bids over 200 since bids cannot go lower than 0. Bids over 200 have an influence on the NBa which can’t be counterbalanced by simply bidding lower. So some boundary on the max/min bids is probably wise. It’s estimated that ±1% of NB is a reasonable bound, depending on the frequency of BLS updates.
We could get meta and say why stop at bids on rewards… why not bid on the rules of bidding? We could have a set of different rules, a) use bonuses b) use median/average c) use a weighted curve d) exclude outliers e) weight by age f) weight by speed etc and also bid on the portion/timing factors. Nodes could bid on which rules to use and which portions to use them in. This is moving toward governance… It’s probably too soon to be thinking at this next level deeper and there’s a lot of work to do on the existing reward bidding and nmb idea, but it’s good to have it in the back of our minds. Probably it’s not required but it’s fun to think about.
It could be making upgrades much less problematic. The infected discussions on directions to take, the stalemates and divisions within the community (like the bitcoin upgrades). Perhaps not all, but some of it could be avoided by not making upgrades so definitive. If they just add options, it is still up to the users to dynamically vote for new or old options, and also change their mind at any time. It becomes a much more democratic implementation, as users will in real time change the system behaviour according to their assessments of real world situations.
What about allowing negative values for bids? Negative reward means vaults must pay to survive! That seems untenable but it might be useful for a) increasing scarcity and b) increasing the number of spare coins when close to 100% are issued. There’s a risk that it’s going to be abused for putting pressure on weak vaults, but it’s fun to think about especially with respect to calculating NBa results.
Additional markets for bidding. Considering that the bid is a valuation of a GET, future rewardable resources within SAFENetwork would probably have their own bidding. What things other than the reward might benefit from a bidding mechanism? For example, computation would be handled in some minimum unit - in the same way as the GET of a chunk - and network nodes might bid for these. At that point we would have two markets, one for the storage and one for the computation, and they would be traded separately with the native network currency. How separate (or connected) should these markets be?
Store cost Although store cost is not necessarily connected to farming reward, a suggested method for deriving it is presented here.
The store cost most favored in combination with the PA system, is a function of farming reward, weighted by the current read:write ratio, and possibly also unfarmed supply (as we otherwise will not see net farming, and could/would stay at 85% unfarmed, perpetually). The weighting by r:w ratio is motivated by the idea that every PUT has the data chunk’s expected lifetime of GETs infused to it; it needs to pay for all the GETs the chunk is predicted to have. An expected result of this, is balance in unfarmed supply.
With this design, the store cost would be directly connected to the decentralized valuation that the PA constitutes.