What is the value of Hive bandwidth?
To answer this question there are a few variables that need to be considered.
- How censorship resistant is the network?
- Does the data being stored benefit from this permanence?
- How much current demand does the network have?
- What is the supply? (22 KB/sec)
Censorship Resistance
No one ever complains about not being able to perform an operation on Hive (except our good friend Justin Sun). In this respect many make the claim that Hive might not be censorship resistant because such and such post got downvoted. Luckily that's not what censorship resistant means so that argument can suck rocks. For the most part Hive appears to be highly censorship resistant and there is very little evidence that points to the contrary. I can still link back to every post I've ever written back to 2017 (and there are some WILD ones) and they are still right there on-chain.
Utility
But how much value does censorship resistance actually have? Do I really need a guarantee that everything I ever write will be immortalized forever on this blockchain? Even as a staunch advocate of Hive I must admit that it wouldn't be a deal breaker if old posts that were 5-10 years old started dropping into the void.
The real utility of these ledgers is to make sure all the money is meticulously tracked. Double spends must be prevented. Negative balances must be avoided at all costs. This is an issue that applies to every blockchain, and for the most part every blockchain does a pretty decent job of keeping these issues in check.
Demand
The demand to actually use the Hive blockchain is very low. How do I know this? Because I've never seen an error that our blocks were full (except for that one time I filled up an entire block with garbage) Interestingly enough a Hive block is barely big enough to fit a 'short' length PhD thesis.
The point being that it's hard to know the value of an asset when supply massively outstrips demand. 22 KB/sec is a very very small amount of data to be processed, but this is the nature of decentralization. A chain is only as strong as its weakest link. Putting more tension on the chain is guaranteed to force nodes to shut down because they can no longer afford the additional resource requirements.
At the same time Hive has been doing a very good job at outsourcing bandwidth off chain to avoid the unnecessary bloat that occurs elsewhere. At this point it's getting quite ridiculous considering we have BRC-20 tokens on Bitcoin and DRC-20 tokens on Doge. These devs just can't seem to stop themselves from putting data in places it's not supposed to be. Luckily on Hive we have yet to experience this issue, and it's quite possible we avoid the entire scenario entirely based on how our network is built.
I've yet to see anyone complain about the rising cost of fees on Hive (and indeed they have been rising). Fees are free™ in the form of yield-farmed bandwidth. The chance that an account like mine would ever run out of RCs is basically zero and it's nice to know that everyone on Hive has this type of security and guarantee. No one here has to worry about bigger fees ruining their entire business model going forward.
What was the title again?
Right well, long story long, I get the feeling that it would be quite possible (if not probable) that scenarios would arise in which RCs are being traded for things that aren't Hive bandwidth. Of course at the moment it's impossible to transfer RCs directly, and the only way to go about it is with a delegation (so the regeneration rate is transferable but not the token itself). Certainly it's not too big of a stretch to assume that RCs would have such functionality extended to them if it was deemed necessary, but that's not really the point (and also likely unnecessary).
The point is that RCs are interesting, and the hyperinflationary nature of them (regen 100% in 5 days) lends itself to some interesting mechanics.
For starters RCs could provide the basis for micro-charging and value streams. Hive already has the capability to provide micro charging using the main tokens Hive & HBD, as it's trivially easy to send someone 0.001 Hive or HBD. A tenth of a penny is a pretty small transfer to be sure.
However, RCs are off the chain.
When someone gives someone else an RC delegation the initial operation does show up on the blockchain and is signed with the posting key. But then what happens? That account will continue to get RCs forever until the delegation gets revoked with another operation. In theory, a delegation could be given to someone for an entire year, and for the entire year value would be trickling into that account constantly without anyone having to sign a transaction to the blockchain (virtual transaction).
The virtual nature of value transfer such as this is quite useful.
When an operation is virtual in nature, it does not require permission to be executed. They require no signatures and all nodes execute the code independently without talking to one another. This mechanic allows bandwidth to be conserved and creates smaller blocks. It's also a secure solution because all these virtual operations feed into the hash of the next block. If a Hive node 'forgot' to run one of these virtual ops it would produce an invalid hash and the bad block would be pruned from the chain.
In some regards we can start interpreting RCs as a kind of safety net. What would happen if direct micro-payments on Hive were no longer viable because of a massive demand for Hive bandwidth? Now here's a problem we'd like to have because RCs would have a non-zero value and could be delegated into a zero-bandwidth value-stream.
To give an example
Let's say I was running a really badass full-node on Hive and I wanted to make sure it was always blazing fast and never got bogged down. The only way to guarantee my node doesn't get overloaded is to limit the number of connections it will service. How do I choose one connection over another? Paid service. Such is the nature of WEB3.
The problem with charging users for service in this regard is that it is very much the antithesis of WEB2. There are certain services that users expect to get for free, and accessing the API of Hive is almost certainly one of those things. Currently we are handling this problem using reputation and block-reward incentives. Witnesses have an incentive to provide these free services out of pocket to boost their reputations and get into or near the top 20 consensus cluster.
Problem with this is that I don't think it's very scalable, and if it is scalable I don't think it will scale in a very decentralized way. It would certainly be better if there were more ways to incentivize the community to provide infrastructure, and creating services that are paid for directly is the easily path in that regard.
Managing accounts and payment.
Not only do users expect free service, but also simply creating an account can be a total pain in the ass and barrier to entry as well. Luckily on a network like Hive the accounts already exist and are enforced by encryption, so that's already a better solution than WEB2 across the board. Any user with a Hive account already has an account with the services connected on Hive. All one has to do is sign an off-chain message proving they control the posting key to the account and they find themselves immediately logged in without having to do anything.
And as for payment.
Again, nobody wants to pay; they want free service. But what if the payment required was simply an RC delegation? At this point in time that's basically pretty much free in the vast majority of circumstances. What would some random Hive node do with all those RCs? Probably just claim account tokens for the time being.
As of now we don't have the infrastructure to monetize RCs in a centralized way such as this, but that wasn't the point, was it? The point was to create a really fast node that never gets bogged down by requests, and a node that charges users RC delegations is a very easy way to accomplish such a goal without fully enraging the users of the node.
Now if one of the accounts connected to our node is making too many requests and sucking up too much bandwidth we can just cut them off with an error message saying their account is out of RCs and they need to delegate more to keep the party going. It is in this way that I believe Hive can start utilizing the RC system for off-chain activity that is still firmly connected to the Hive ecosystem.
What about p2p delegations?
The above example was a many to one relationship where perhaps thousands of users would be delegating RCs to a single infrastructure provider in return for off-chain services. The "subscription fee" would be in effect the RC delegation.
Get paid to ______
However, as infrastructure on Hive matures and there are more and more ways to get paid on-chain, RCs could become an extremely valuable resource. I've had a bit of an epiphany in the last 5 seconds, and the ultimate goal of all users on Hive is essentially to engage with the process of alchemy. We take a resource that is abundant and cheap (RCs) and attempt to convert those resources into something that is more valuable (digital gold if you will).
In fact that's exactly what I'm doing right now.
I'm writing a blog. The value of RCs rounds down to $0, so all I have to do is get a payout above $0 for this conversion to we worth the hassle and not lose money. However, the RCs required to write such a post will not always round to zero. Hive becomes exponentially more valuable as different types of the conversions and associated datasets are created. Or at least that's the theory.
I've already seen this play out on the micro side.
I've seen dozens of gamers on Hive asking why they can't post to chain or begging for RC delegations. Operators essentially have two choices: let the players figure it out themselves or provide the free service experience by auto-delegating out to new players. This is almost certainly an issue that will escalate over time.
Another idea I've considered is the one of RC loans. If the goal of RCs is to perform alchemy and produce an asset of greater value, then this lends itself to a model where new users can be delegated RCs with strings attached. Get an RC delegation today and trade me your gold tomorrow to pay back the loan type of deal. These loans would be so low-risk that they would almost certainly become profitable even given Sybil attack exploits. Just another thought rattling around this brain here.
Conclusion
RCs have a value of zero today, but we have to expect that given any kind of adoption this will no longer be the case. No matter how big Hive blocks are they will always be small enough that a single killer dapp would fill them all to the brim. We must expect that eventually RCs will become scarce and that users will have to carefully pick and choose what to put on-chain during their trials as a Hive alchemist.
RC delegations are extremely powerful on Hive because they provide the base resource required to interact on the chain in addition to a doubling as a micro-payment stream of value. Because the asset is hyperinflationary and gets destroyed just as fast as it gets created (hyper-deflationary) this mechanic allows these value streams to exist and continue being calculated without the need of constant on-chain signatures. In this regard it's somewhat like the Lightning Network (pay to open ; pay to close) yet is better and more decentralized than LN. Cheers! 🍻
Return from RC Alchemy to edicted's Web3 Blog
