Initial thoughts on Züs Blobbing
As an active participant and blobber (storage provider) on the Züs “pre-launch” mainnet, I’ve seen some unexpected strategies that have emerged from its current economic model. I intend to share my findings, identify the issues, and suggest potential fixes before we scale to larger numbers.
Gaming the blobber system
A blobber who sets cheap write prices isn’t gaming the system at all; it’s actually quite the opposite. Blobbers are incentivized to maximize their write price. A glance at atlus.cloud shows that many of the top-earning blobbers have a high write price and/or have maxed out their write price to 25 ZCN/tb/yr. Even Saswata himself has stated that blobbers should “increase pricing… the client has to spend to do this attack.” So, if low write prices is the way to “game the system” it certainly isn’t playing out that way so far.
The Zombie attack
Setting low write prices leaves you vulnerable to zombie allocations: a scenario where a competing blobber (or bad actor) buys a cheap allocation with no intention of storing files. Their motivation is to buy up your allocation capacity, thereby reducing your blobber’s capacity for others to purchase and, consequently, neutralizing you as a threat to their block reward share. This attack is more lucrative for those blobbers who are charging a low write price on new allocations. Thus, the network, as it currently operates, incentivizes a high write price, not a low price.
What top-earning blobbers are doing is the following:
- Secure low-price allocations involving only their blobbers. Once they have secured enough low-price allocations, increase the write price (to disincentivize outside allocations — allocations from outside/unknown parties)
- Then self-deal junk data on their own allocations.
I can validate this because I am engaging in the latter myself. However, I initially set a low write price, assuming it would be in my interest to welcome outside allocations.
The real problem
This is why I argue write price isn’t the issue when it comes to gaming the system: self-dealing is the real problem. Self-dealing is storing files on your own blobber to earn more storage provider rewards. The current blobber block reward model not only incentivizes self-dealing but also discourages offering storage to ‘unknown’ parties and encourages blobbers to attack other blobbers who do not price out unknown parties. This is not conducive to network expansion. It encourages closed loops of self-dealing by high-capacity rigs with high ZCN stake and an adversarial storage provider ecosystem where blobbers are attacking other blobbers.
“Blobbers are attacking other blobbers”
Here’s how it works. If you notice another blobber with high ZCN stake and high unallocated capacity, you will put them in the crosshairs as a threat to your block reward share. So, if you’re earning 2500 ZCN per week or more from blobber block rewards, why wouldn’t you buy up all competing capacity? The max write price is 25 ZCN/tb/yr, or 2500 for 100tb/yr. Game theory suggests attacking all blobbers via zombie allocations. The gains from block rewards will outweigh the losses from the attack (assuming you’re generating rewards).
A proposed solution
Is there a solution? I believe so. As a blobber who is currently engaging in self-dealing, I can attest that there are three fixes that would significantly impact my ability to exploit the system:
- Only attribute ‘weight’ to successful challenges on allocations that are random — you can’t earn block rewards if you specify a specific blobber ID. (Currently, I can choose my own blobbers and fill them with data.)
- Require a large data/parity set on allocations — you can’t earn block rewards if your allocation doesn’t have an erasure-coded set of at least, say, 8 data blobbers and 4 parity blobbers, or a similar configuration (with perhaps more weight given to larger EC sets).
- Prohibit allocation upgrades to a larger size — otherwise, I would just spam 100MB-sized allocations until I got my preferred data/parity set and then upgrade the size to 100TB.
This approach means that if I were to attempt self-dealing, I would need to roll the dice and hope I mint an allocation that contains my blobbers. And if I do get lucky, I would be able to self-deal but would also be storing files on other random blobbers. These fixes wouldn’t necessarily eliminate the issue (for example, I could still spin up 20 separate smaller blobbers and try to expand my chances of allocation inclusion), but it would make it exponentially harder to game the block rewards than is currently the case.
Just my two ZCNs. Cheers!
~ Feebs
