Hive Scaling vs Bitcoin

edicted (82)in LeoFinance • 3 years ago (edited)

Everyone touts Hive as a fast and feeless network that can outscale the vast majority of other projects, but is this actually true? If so, to what extent is this true?

I decided to do some basic math to figure it out.

First, lets take the network that scales the least: Bitcoin.

What is the maximum size Bitcoin block?

Technically, the maximum Bitcoin block size is supposed to get capped at 1MB, but if we check a block explorer what do we find?

https://www.blockchain.com/explorer

All Bitcoin blocks are actually above this limit and go as high as 2MB. I assume this is due to a technology called SegWit (segregated witness).

SegWit is the process by which the block size limit on a blockchain is increased by removing signature data from bitcoin transactions. When certain parts of a transaction are removed, this frees up space or capacity to add more transactions to the chain.

So actually that's... not what's making them bigger than 1MB.
What could it be what could it be.

Today's Bitcoin uses a piece of code called Segregated Witness (SegWit) to separate signatures from transaction data, effectively allowing the network to “cheat” by creating larger blocks than 1 MB, yet still counting them as being below the cap.

Alright whatever I guess it's just SegWit...

ANYWAY...

What's the max blocksize on Hive?

Currently 65KB per block. That's a lot smaller than a Bitcoin block, but obviously this isn't a big deal because we have one block every three seconds while Bitcoin has an average time of 10 minutes. On average, for every one Bitcoin block there will be 200 Hive blocks.

200 x 65000 = 13,000,000 (ignoring that 1KB = 1024 bytes)

This was very surprising to me.

If Hive's blocks were filled to the brim we'd only be storing ten times more information than Bitcoin. That isn't a lot. Considering how much space blogs are taking up and games and everything else it's very obvious that if Hive was ever as popular as Bitcoin is today we'd have to make some serious changes and sacrifices to keep up with demand.

Why not just raise the blocksize?

This is something that Hive can do much much much easier than Bitcoin. It's a lot easier to get consensus with 20 witnesses than it is to get consensus for the entire network. The problem with increasing blocksize is that it makes nodes more expensive to run. More expensive nodes means that anyone outside the top 20 witnesses might drop out due to prohibitive overhead costs (RAM, bandwidth, etc). Bottom line: increasing blocksize greatly centralizes the network and makes it harder for new players to join the party.

This is why there has been so much controversy over raising Bitcoin's blocksize. This is the exact argument that created Bitcoin Cash and many other Bitcoin forks. The main chain wants to stay as decentralized and cheap (to run a node) as possible. They are holding out hope for other scaling solutions that won't add burdensome overhead costs to the node-runners.

It's also EXTREMELY premature to be discussing increasing the blocksize limit because we've yet to stress test our current blocksize. We have no idea how expensive or unstable the network will become when we start hitting that 65KB barrier. According to the math it will cost at least x10 more money to run a Hive node than a BTC node at that time, and that's not even factoring in all the unique indexes we have to keep track of in the database due to blog posts and everything else.

This is why @blocktrades and friends spend so so much time on optimization. If we don't solve these problems now, by the time we actually get adoption, we won't actually be able to accommodate the users. This is exactly what happened in 2017, and we are scrambling to avoid a repeat of that scenario.

Hive has other advantages.

The DPoS consensus algorithm has a lot of hidden technical advantages behind the scenes when compared to its POW and POS counterparts. The biggest advantage that very few people seem to take into consideration is that we know exactly which node is going to produce the next block. This known fact shaves an entire layer of complexity off the top of our consensus layer.

https://hive.arcange.eu/schedule/

@arcange created this neat little tool to show us this advantage in real-time. On other networks, every node needs to broadcast unconfirmed transactions to every other node. All nodes need to know which accounts want to perform which actions BEFORE they are actually added to a block. That's because any of these nodes could be the next block producer, and they all need to know what's going on with the network.

With Hive this is largely unnecessary.

When any of us need to broadcast a transaction, we can connect to any node in the network. That node that we connect to knows exactly where to send our information. They don't need to broadcast it to the entire network; only the witness who we know is next is line to post the next block. This is a nice advantage to have.

In addition to this advantage, after the block is created, what happens next? The witness node that created the block needs to broadcast it to the network, but who should they prioritize? Obviously, the witness node in line to create the next block is the #1 priority, as that witness can not create the next block without having the information contained in the current block.

This streamlined assembly line of block production is a huge advantage over networks like Bitcoin and friends. We know exactly when and where information needs to be, and this will allow us to scale up with a lot less problems if and when we do decide to increase the blocksize.

3-second blocks

Of course I would be remiss if I didn't mention how this structure of block-production also makes it possible to have lightning-fast block-times. Having to wait ten minutes for a Bitcoin block (sometimes as long as one hour) is not acceptable for a lot of people.

On Hive it only takes 3-seconds, and for blocks to become completely immutable only takes 1 minute, whereas most exchanges require 3 Bitcoin block confirmations which could take hours on the unlucky side. It only takes 1 minute to get Hive onto a centralized exchange to be ready for trading. Not to mention it only costs 0.01 Hive (< 1 cent) to move Hive off an exchange... whereas it can cost up to 0.0005 Bitcoin ($30) to do the same.

You get what you pay for?

Some would say Hive sacrifices a lot of security in order to get this higher level of scaling. I tend to disagree. We've yet to see the system fail, and we've yet to see anyone's money get "stolen" except for the one bad-actor that was trying to do the network harm. Considering how difficult even that was to accomplish I must assume that Hive security is a "good-enough" solution just like Bitcoin is. None of these systems will be perfect, and they don't need to be. We all have our niche to fill.

Resource Credits

A big piece of Hive scaling is the RC system, which is due for a big upgrade soon™. Many do not realize this, but Hive is basically the original DeFi network. Not only can our HivePower create more Hive, but our HivePower also creates more Resource Credits, and this all happens automatically for free.

Because RCs currently have a value rounded down to zero, many discount this resource as a nothing-asset. LOL... yeah... just wait. RCs are going to be the most important asset on the entire network once blocks fill up. It would be silly to assume that this wouldn't happen, as we are running this entire operation on 22KB per second. I repeat: we are running this entire network on 56k modem speeds and no one yet realizes that bandwidth is going to be an issue. Why? Because it never has been before. Have some vision. 22KB per second is not a difficult target to hit.

This is a great Ted Talk about trying to fix traffic jams. A freeway doesn't get clogged until it has just a tiny bit too many cars on the road. Removing 10%-20% of the cars on the road from a deadlocked traffic jam will completely clear all traffic. Think about that for a moment.

Because Hive is exactly the same way. Bandwidth is like air: you don't give it a second thought until you run out. Hive is 100% guaranteed to run out of bandwidth sooner or later, and that's when things start getting interesting.

As of now, no one gives a second thought to posting a comment or playing a game on hive. These are things we can do for free because there is zero competition for resources. Once blocks fill up the entire game changes. Users have to pick and choose what they will and will not put on chain. Bots that play Splinterlands will drop off the face of the Earth. RCs will go from zero value to some value, which will completely change the game.

And at that point it will be very hard to make the argument that Hive has free transactions. We don't. No network does. You can't run an inefficient node network for zero cost no matter how many whitepapers you write.

Of course we gain the supreme advantage of separating our monetary resource from our bandwidth resource. Those who hold vast quantities of Hive will have a replenishing resource pool that just keeps farming valuable bandwidth. Those who want access will either have to pay for it or provide value to the network with their actions.

So say you're playing a new farming game on Hive and you need access to bandwidth. No problem, the dapp creator of the farm game has an RC pool up and running and he'll give you access to it should you need access. However, if you want access to said RC pool to play the game you had better fork over some of your in-game wheat to pay for it. Maybe you only have to sell 10% of your wheat to pay the overhead cost of farming it on Hive. Pretty good deal, amirite?

This is how it's going to work.

RCs will be used to create resources/tokens that are worth more than the RCs used to create them. Those who don't have their own RCs can simply pay a tax from the other tokens they've created to gain access to an RC pool. The RC pool owner will use that tax to buy even more Hive, so that they have access to even more RCs. The direction we are moving in is bursting with abundance.

Checkpoints.

It becomes clear that eventually much of what goes on inside the Hive ecosystem will have to be outsourced to 2nd-layer protocol. We can even create checkpoints and nodes that don't store all the information that a full node would. Rather than having to store the last 5 years of information a lite-node could instead store the last year of information and import a snapshot to represent the 4 years of activity before that. These nodes won't be storing blog posts older than a year, but everyone's account will have the correct number of coins in the right place. Something to think about, as this is the only way to make blockchain sustainable over time.

Conclusion

All I can say is: holy god make sure you have enough Hive to yield farm these resource credits once they are actually worth something. Looking at the new 3speak airdrop and considering my own proof-of-burn architecture, once this snowball starts rolling it's not going to slow down for quite a while. Those who do not grandfather themselves into this network now are going to very much regret it down the road as they're being forced to pay for bandwidth on a network in which they thought transactions were free.

With the way we talk about Hive, I'd of thought our scaling was x100 or even x1000 times better than Bitcoin. Simple fact of the matter is this is not true. Not even close. x10 max at the moment. However, we have a lot of room to grow and a lot of our mechanics will allow us to breach certain scaling barriers over time that Bitcoin and friends will have a very hard time with. The future is coming. Will we be ready for it?