This common theme pops up over and over again when it comes to the Resource Credit discussion on Hive. I'll say something like,

The cost of transactions on Hive is going to get very expensive; resource credits are going to run out.

And what response do I get?

Oh well, plenty of whales aren't using their credits so if we run out of credits there are plenty more where that came from.

WHAT?!?

Uhhhh... no... that can't be... no...

_noe

I mean, sure, it SOUNDS right.

If there is a shortage of RCs, and there are a bunch of whales that aren't using their RCs, and we open up RC delegations, then we'll have plenty of RCs to go around, right?

No though...

Because RCs aren't the real asset. RCs are just a ledger telling us which accounts have access to the real asset. Does anyone care to venture a guess what the real asset is? I've talked about this at least a half dozen times over the years.

Users on Hive don't seem to understand that the cost of operations can go up dramatically if we end up seeing the increased usage we are looking for. So when someone tells me, "Don't worry whales have plenty of RCs," I'm thinking, "Wow.. okay... but that's going to make the problem even worse."

Exponentially worse.

Does anyone remember what it was like when everyone was paying bidbots to upvote their garbage to the top of the trending tabs? That's what we call rent-seeking behavior, and it is not ideal in many circumstances (especially the trending tab). The trending tab's goal is to curate the best content for everyone to see. If we allow people to rent the trending tab like we did during the bid-bot era, then the trending tab's entire purpose has been toxically monetized and undercut.

Uh okay, what does the trending tab have to do with RCs?

It's the concept of rent-seeking behavior that becomes extremely valid in this case. We are constantly marketing Hive as a place where users can come to get free transactions. That is simply not true. All transactions across all blockchains cost something. This is a fundamental requirement to avoid Sybil attack, DDoS attack, and mitigate all manner of threat vectors to these networks.

This is the fundamental difference between WEB3 and WEB2.

WEB2 was founded on the free-to-play idea that offering 'free' service is the best policy. 'Free' service leads to the most users. The most users leads to mountains of raw data and advertising revenue by organizing that data into a targeted function. It is in this way that WEB3 shares more similarities with WEB1 (subscription model) than it does with WEB2. We are coming full circle with the ideology, and the transition phase is brutal.

Have you had enough time to contemplate the true resource that RCs give us access to?

Spoiler alert: the answer is on-chain bandwidth.
Actual on-chain bandwidth is the real resource. Getting your operation onto a block is the real resource. RCs are just a ledger to determine who gets their information on a block.

So again, when someone is like, "Whales have plenty of RCs," I'm like... holy hell... yeah, and when they engage in rent-seeking behavior and start selling their RCs for a profit, that's going to destroy the entire narrative we've been peddling from the beginning (that's operations on Hive are free). Which is fine... because they are not free.

But also when the whales start doing this, what's going to happen? Hyperinflation. RCs that were not in the ecosystem will now be constantly dumped onto the ecosystem for their share of bandwidth (now that bandwidth has a non-zero value). So when I say that we will run out of RCs, whales dumping their RCs on the network means the problem gets exponentially worse. The cost of operations is going to skyrocket when our blocks (bandwidth) fills up.

Level 2 noob argument: we will just increase the blocksize.

Inevitably this is where the conversation naturally leads to next. Okay well if RCs are virtual and the real asset is blocksize, then we will increase the blocksize. Again, this is objectively false. Hive is already overclocked to the point of guaranteed instability when the blocks are filled. Scaling an inefficient decentralized network is the hardest thing to do. That's why everyone talks about scaling. It is the primary goal for mainstream adoption.

Failing to scale, gracefully over time.

To just assume that Hive can beep boop beep scale without going through trials and tribulations? That's simply ignorant and borderline delusional. We run this entire network on 22KB/sec, and every time we've been stress tested at these levels we've been shown that the network becomes too unstable. So again, the "we'll just increase the blocksize" argument goes straight out the window.

Say we run out of resource credits because the cost of operations increases. Now RCs have a non-zero value. Whales come in offering RC delegations on the cheap. This is guaranteed to make the problem worse by increasing the cost of transactions even more.

Do I think RC delegations are a bad idea?

No I think they are a great idea and fix a ton of problems. That doesn't mean that they won't lead to a rent-seeking system where new users have to pay for transactions on Hive. Hive is one of the few networks that allows users to yield farm bandwidth itself. It only makes sense that weird stuff would happen that doesn't happen on other chains that require payment upfront of the main token.

Yeah well that's not a 'now' problem.

Now this is something I agree with. If we see RCs increase to a non-zero value, the price of the Hive token will absolutely skyrocket. Again, this is something I've mentioned a lot: I wouldn't be surprised to see Hive go 100x in that scenario. Of course that result leads to more instability and volatility, but who cares, amirite? 100x is 100x. Just don't be the sucker that buys the peak. Sorted.

We've yet to see how this concept of yield farming bandwidth is going to play out. We've basically never run out of bandwidth on Hive. We've never choked users so hard that they had a difficult time getting access to RCs. We've never had RC delegations. A lot of variables are going to be interacting all at the same time and we are sure to be surprised by the emergent outcomes of a complex economy.

So how hard is it to choke the bandwidth?

How hard is it to use 22KB/sec for every single person on the network? Granted, that 22KB/sec is all text, but at best that's only 22k characters per second for all users on Hive to share. Even if we were somehow able to double the blocksize (we can't at the moment) that's only 44k character per second for all users. That's a very very tiny amount. A single popular dapp (probably a game) could gobble all that bandwidth up instantly.

Deflationary

The fact that bandwidth is farmed on Hive by stakeholders makes it inherently deflationary. Even though it seems like RCs are printed to infinity and everyone has full access to the network at all times for "free", that's just because we've never been properly stress tested. When supply of the actual bandwidth resource gets choked, we will see just how deflationary RCs become. Users who were once able to post to the chain 100 times a week (more than they use) may find that number get cut down to 10. They'll either need to post less data to the chain, buy Hive and power-up, or get an RC delegation.

But why deflationary?

From another perspective, the supply and value of RCs will appear to be hyperinflating. It just depends on how we look at it. I would call it deflationary because (like Bitcoin) the users that were here first have access to all the resources, and new users coming in are going to get railed by volatility. That's an extremely deflationary thing to happen (hoarding resources and a complete lack of elasticity). The hyperinflationary angle is also a valid one. They both lead to the same results and they are founded on the same principals. Only the perspective we view the issue from differs.

This is actually already happening.

A few months ago some random was in Discord asking for a delegation so they had enough RCs to post to Hive. I delegated them something like 10 Hive thinking this would be more than enough to make at least one post. It wasn't. I was amazed to realize that even after delegating 10 HP he still somehow didn't have enough credits to post to the chain. Mindblowing, as 10HP a year or two ago would have been enough for like 10 or 20 posts a week. This situation is going to continue to escalate as Hive blocks fill up. It may require 100-200 Hive just to get free transactions. Imagine how crazy that would be given a $50 token price. All of a sudden a new user needs to invest at least $5000 into the network just to yield farm bandwidth to maintain operations. Mark my words: we are going to see some crazy stuff. It might take 5 years, but it will happen.

Stability and consistency

The really nice thing about yield farming bandwidth on a network like Hive is that this leads to a certain kind of dependability and security when speculating on future events. Someone who builds an app on Ethereum may find that their model is completely broken after network fees skyrocket by x10.

On Hive this isn't a problem assuming the agent in question powered up enough Hive to keep the lights on five years down the line. Again, this allows users to buy in today knowing they'll be taken care of later. The tradeoff is that scrappy newcomers may have a very difficult time entering late to the party, even if they are bringing more value to the network than the old players.

Conclusion

This is something I've spoken to many times, but users still don't quite seem to grasp it. Repetition is key to learning anyway. I should know. I feel like half the time I'm writing this blog just to reinforce my own knowledge of the topics and help myself remember them and keep them organized.

The bottom line is that the resource credit system on Hive is just a secondary token used to outsource the ledger on our bandwidth. It's a very unique system when we actually study it. We still don't know how it's all going to play out, but there's plenty of things to speculate on.

Posted Using LeoFinance ^Beta

Return from Resource Credits are Virtual Assets to edicted's Web3 Blog