Hardfork26 Update & RC Angel by @deathwing

So it appears as though the Oct 11 launch of HF26 isn't going to be pushed back this time.

Let me make sure... as I haven't been following too closely.

The new release candidate still has a date of Oct 11th for the date of the hardfork. Based on the relatively small number of changes made in the latest release candidate, I don’t currently see any reason to extend the hardfork date out further in time.

Witness clique is a buzzing.

Yesterday I was approached by @deathwing who asked if I would donate my RCs to his project.

Which project?

Check the top post of the trending tab.

Oh... flex!

Oh... nice!

So because Hive Core devs opted to do direct RC delegations rather than pools (to simplify the complexity) @deathwing is going to create a "second layer" version of RC pools on top of Hive called "RC Angel". RC Angel will be open source tech that can be employed by multiple parties. Each of these accounts would emulate a virtual RC pool.

Centralization to avoid complexity.

The way RC Angel will work is requiring RC providers to fork over their posting key authority to whatever entity is running the code (of which there could be multiple options just like we can pick which Hive nodes to connect to). This centralized account will then provide new users or those that run out of RCs with a delegation so they can continue posting to the chain.

It's cool that @deathwing is really hitting the ground running with code like this before HF26 has even launched. Much like HiveEngine is a centralized testnet for tokens and smart-contracts on Hive, so to is RC Angel a relatively simple fix to leverage RC delegations into RC pools in a permissionless way that doesn't require a hardfork.

[Refresher on what RC pools actually are.]

RC Pools Coming Soon™

Dated October 14, 2018, we can see this upgrade has been a long time coming. I guess we can chalk it up to @Ned's complete and utter failure as a competent leader. That being said, now that we are in the position we are in... I'd say I prefer it this way.

RC Pools are Priority #1

Dated Aug 19, 2021, again we see the importance of RC pools. Basically how it should work is that the pool is composed of two types of people.

1. Users who put RCs into the pool.
2. Users who have access to the pool and use the RCs provided.

One of the really cool key functions of RC pools is the efficiency of them. It's basically a fractional reserve, which I'll admit doesn't work too well for creating sustainable banking practice, but in terms of RCs it will work quite nicely. Essentially the pool will be able to delegate more than 100% of it's resources out to the users who need them.

For example, say the pool had a million resources inside it and 100 users with access to the pool. Common sense would dictate that each user would get access to 10k credits (1M / 100 = 10k). However, with resource pools each user could be given access to 100k credits if that's how it was set up. Problems would only occur if the pool ran out of credits, which is unlikely in many cases because even though everyone has access to 100k credits, many of those accounts will use much less than the average 10k per account (zero if they are inactive at that time). The bigger the pool the higher chance that it can manipulate permissions across users to create a stable solution.

This is all part of the process of increasing the value of yield farming bandwidth as a derivative asset. Hive is the original DEFI network. By creating an efficient network of RCs we can finally start measuring our actual ability to scale rather than just assuming it works in theory. Many RC costs will be increased during HF26 in three days.

I had no idea that claiming accounts was going to increase in price by x15. That's wild. I hate to say it but... I told you so. I said RCs would become a very scarce resource in the future, and this is only the beginning. Personally I think it's a bit of a bad sign that Hive is going to be creating less accounts for "free" and this speaks to our actual scaling limitations that I have mentioned half a dozen times over the years.

Why Do Hive Accounts Cost Resources?

This is a very valid question. We can create a Bitcoin wallet or an Ethereum wallet for free... if Hive is so scalable, why wouldn't we be able to create a Hive wallet for free? The answer is a simple one: Hive wallets are on-chain whereas many other iterations of blockchain are not. Allow me to explain because obviously that sounds weird.

Take my own account @edicted for example:

https://hiveblocks.com/@edicted

My account was created on December 18, 2017.

We can see this on PAGE FOUR THOUSAND SIX HUNDRED SIXTY.

Let that sink in for a bit.

Compare my on-chain activity on Hive compared to something like Bitcoin. It's possible to be a hardcore Bitcoin investor and only have a few dozen transactions on-chain. Anyone who uses a custodian like Coinbase can invest in Bitcoin and never put a single operation on chain. Instead they'd just be buying/selling directly from the connection to their legacy bank account; allowing Coinbase to hold a stack of coins in cold storage that never moves, while batching thousands of users together within a single transaction when cold storage needs to change the total collateral amount.

More importantly:

The reason why anyone can make a Bitcoin wallet for free? Like I said, wallets do not appear on-chain. A wallet only exists on Bitcoin server nodes when actual Bitcoin is transferred to said wallet. In essence, the fee is paid to the miner when this transaction is made, so in reality, even creating a Bitcoin wallet costs money (unless it's empty). However, the thing about Bitcoin and many other chains is that it charges the sender the fee rather than the owner of the account like we do on Hive. This is one reason why onboarding can be difficult on Hive and why we jump through so many hoops to provide "free" service to users for a better experience and first-impression.

As we can see above, a Hive account contains:

1. A recovery account.
2. A username
3. A posting key
4. An active key
5. An owner key
6. A memo key
7. The master key is not on-chain and exists as an off-chain tool to create the other keys.

That's a significant amount of data.

And thus it can not be allowed to bog down our servers without some kind of fee being paid to prevent a Sybil attack. Actually just the other day @lopp (my favorite libertarian Bitcoin Maximalist) on Twitter was showing how both Bitcoin SV and ZCASH are under attack by these exact kinds of data bloat attacks. Apparently the ZCASH one is only costing $10 a day and has already tripled the size of the blockchain after what looks like around 3 or 4 months. Hopefully the RC system will be fine-tuned well enough to avoid these kinds of hacks.

RAM Index

There are many raw data points on the Hive blockchain that are subsequently leveraged into a sorted RAM index onto the full nodes. This RAM cost adds up and can become very expensive, as we all saw what happened to EOS and the speculation/hording that occurred there.

Examples of these kinds of fast access indexes would be:

1. A list of blog posts a certain user posted.
2. A list of the hot/trending/new tabs.
3. A list of user operations (biggest one by far I'm told).
4. A list of users and associated financial information (wallet balances, powered up Hive, HBD, savings accounts, etc)
5. ETC ETC

In order for Hive full node APIs to be as fast as possible, these sorted indexes need to be constantly maintained and stored in RAM. It's easy to see how all of these things can add up, and none of them apply to something like Bitcoin that only does basic payment from one wallet to another. It is for all these reasons and more that Hive MUST charge users to create a wallet. It is also why I have equated Hive accounts to NFTs, because they store a lot more information than just token balances.

This becomes somewhat of a double-edged sword. It's cool that Hive accounts have so much data/reputation associated with them, but that data comes at a cost. Nobody said scaling is easy (and if they did they were selling something).

Again, I was very surprised to hear that x15 less free accounts will be allowed to be minted on Hive starting in a few days. As I have stated multiple times now, the ability to create new accounts is going to be a big bottleneck during mainstream adoption. This is why I've theory-crafted projects like Love Handles way in advance that would allow users to buy and sell accounts just like they would any other NFT.

It's also significant to note that keeping our owner key safe in the future will be even more important than it is today. Today we can recover the owner key in the worst case scenario, but think about a future where anyone can sell their account to anyone. For example: what if there are credit scores and reputations associated with our account?

If we have to recover our account from a hack, our owner key will change. If our owner key changes, many of the reputation systems built on Hive will have to assume the account was sold and changed hands. This could zero-out our credit score or other forms of reputation that depend on this key not changing to ensure that ownership has not legitimately traded hands. Something to think about.

Posting key authority

Circling back to RC Angel, it requires users who seed the pool with RCs to give the centralized account access to their posting authority. This is more common than it sounds for anyone who doesn't have experience with this kind of thing... in fact, I'm willing to bet many of you have granted your posting/active authority to accounts without even realizing it. You can check a block explorer to find out.

https://hiveblocks.com/@edicted

Looks like @threespeak has access to my posting key authority. This means they could upvote, downvote, and even write blog posts or comments on my behalf. They don't abuse this power because if they did they'd lose reputation, but the fact remains that they still have the power while I grant it to them. If they had active key authority they'd be able to transfer my money around and do powerdowns and things like that. Definitely be careful about who you give access to, and make sure to delete old accounts that are inactive or potentially compromised (or even worse ones that were active on Steem but not Hive). To be fair I've never actually heard of anyone abusing this power... which I actually find to be quite surprising. There should have been a huge breach of trust by now.

So again, the centralized downside for RC Angel will be giving up that posting key authority to the centralized account that acts as the given RC pool. This account will technically be able to upvote and post under your name, when all you really want it to be able to do is delegate RCs. It would be nice if there was a permission key below posting that would limit the scope of a product like this.

For example, the posting key would upvote/downvote/post while the new key would be used for RC delegations and custom json and all the lower level stuff. But again... adding a new key to every single account in the system comes at a cost, and could very easily be not worth that cost/complexity. If a centralized agent abuses posting key authority, it's really not that big of a deal in the grand scheme of things, but it is worth bringing up regardless just to have the discussion.

Instant block irreversibility.

Assuming their are no critical bugs with this upgrade, Hive is about to become one of the fastest transaction layers in the world. Imagine how weird it will be to send Hive to an exchange and to receive the email seconds later that the money has been confirmed and ready to spend. Gonna be so weird. How many other blockchains have that kind of user experience? And that's just the icing on the cake, as the real value to reducing dapp lag from 45 seconds to sub 3 seconds is huge. I expect it will need some fine-tuning to get that fast but it will be worth it.

Conclusion

Huge upgrade coming down the pike. Top 20 witnesses like @deathwing are already building on top of it, making upgrades even during the beta test. Exciting times. RCs are only going to become more valuable from here on out. The need to power up tokens to yield farm bandwidth will eventually crescendo as blocks begin to fill up. Don't be surprised if HBD demand starts materializing at the same time. Slow, and then all at once.

RC delegations are massively important. Our @hextech witness runs a little program called @giftgiver. We've been providing HP delegations to new users for years now. With this fork it's possible to separate the RCs from the HP. Onboarding dapps like Splinterlands, Leofinance, and SPK network will absolutely require RC delegations to move forward with giving free accounts to new users without the pitfalls of the bot-army Sybil attack that farms the small delegations for the voting power. Now we can allow accounts to post to chain without giving them voting power. This goes a long way toward a sustainable scalable network. Kudos to Hive Core devs on this one; they've really outdone themselves.