Have I written about these yet?
Let's check...
Oh look I have.
August 30, 2020...
Virtual Operations
So what did I say about them...
Oh wow do not click that link... nobody needs that!
A very dense post on API endpoints and programming and such.
That must have been back when I was still working on Magitek everyday.
When will I pick back up on that project? I do not know.
Soon™
In any case, I just wanted to make sure I wasn't going to just write the same post all over again. Obviously this is not what's happening here.
So... virtual operations on Hive... what are they?
To put it much more succinctly than the post I just linked: virtual operations on Hive are operations that do not require any user on Hive to sign them. In effect: virtual transactions are synonymous with implied transactions. Hive nodes assume they exist independently without actually being forced to verify the information with each other. This has many interesting implications on a game-theory level and is a very efficient way of running the blockchain.
For example, one node doesn't have to verify with another node if an account has enough money to make a transaction. All nodes intrinsically have this information, because all nodes have replayed the entire history of the blockchain and all come to the same conclusions without having to confirm those conclusions with each other. This creates a much more efficient network that doesn't have to constantly confirm data with outside sources like the legacy financial system does. All the data is synced independently on every server.
One of the weird things about Virtual Operations is that they do not appear on the blockchain. You heard me right: they do not exist on the blockchain. More specifically, these transactions don't appear within the blocks themselves on the blockchain, but all the nodes tirelessly track the information anyway. They exist, but also they don't exist. Get it? It's so simple. Yeah, you definitely understand; I can tell.
So basically if you take a peak at blocks on Hive none of this information actually exists, because putting virtual operations into the blocks would be fully redundant and just add bloat to our already grossly inefficient database we call a blockchain.
Why should I care?
Look at the image above that shows all the virtual operations. author_reward is one of them. You like getting rewards, don't you? In fact, all of Hive's inflation is allocated permissionlessly and requires no one to sign off on them; they just happen. Basically these virtual ops are all fully automated functions of the blockchain that we just don't really think about, and then end up taking for granted, like rewards.
Bitcoin halving event.
In many respects the fact that Bitcoin "will only have 21M" tokens is also kinda like a virtual operation. Nowhere in the Bitcoin Core code is there a snippet you can point to that is like, "Here it is: only 21M are allowed." Rather the code that enforces the halving event implies the hard-cap with logarithmic math. Any number that's constantly getting cut in half can never get higher than a certain point. Anyone who's done limits as x goes to infinity on logarithmic functions knows about the asymptote involved.
Easy there, Big Brain McGee, nobody cares!
Right, my mistake.
The point of this here post is to point out how Resource Credits are virtual transactions: they do not appear on the blockchain. In fact they are even less on the blockchain than virtual operations, if you know what I mean (JK I know you have no idea, that's why I'm writing the post).
So again, when we ask the network to put data on the Hive blockchain for us, what does that entail?
- First, we construct the transaction we want to send out.
- Then we sign the transaction with our private key.
- This creates a valid public signature so the network can confirm we control the private keys.
- Once the transaction has been signed, anyone could submit it to any Hive node, and that node would verify that it was valid and forward it to the next block producer, to then be included into a block on the chain.
- I have just described how non-virtual operations work.
However, what if our account doesn't have enough resource credits to pay for on-chain bandwidth? We are told that the network will reject the transaction and we'll have to try again when we have enough RCs. However, this is not entirely true, and nobody is really talking about these things because RCs are so cheap that nobody is really having these problems or being forced to discuss them out of necessity... yet.
First off, how is it not true?
Technically, if a witness wanted to allow someone to put their transaction into a block without the required RCs, they are allowed to do that. In fact, any witness could technically publish any block with any information on it they wanted. However, if the other witnesses decide that block is invalid it would be rolled back.
However, as far as I know, a witness allowing a user to put a transaction on the blockchain without the necessary RCs is not exactly a rollback offense. Rather, that user will pay the necessary RCs, but then their total RCs are allowed to go into a negative balance.
Those of us who were around during the hardfork that implemented RCs remember this well, because most people on Steem had negative RCs and the chain was essentially frozen for days for a majority of users until the system got patched. That patch actually gave everyone a lot more RCs, so if blocks actually start filling up around here, don't be surprised if they start rolling it back and start jacking up the prices. You've been warned.
This is basically something I was forced to learn a lot about during the Steem hostile takeover when rogue witnesses started allowing operations to be put into blocks that were not allowed by the consensus witnesses.
Basically when Justin Sun froze out all the big whales he didn't like, rogue witnesses outside of the top 20 were allowing those frozen accounts to move their money. This forced the sock-puppet consensus witnesses to cancel those blocks and roll back the chain, which ended up causing massive problems and instability on Steem: like Splinterlands games getting totally wrecked and people forced to auto-surrender because the block that had the Splinterlands data on it got deleted due to it being on the same block that was trying to let a whale transfer their money to an exchange or powerdown.
Interestingly enough, this was a classic case of using our own code against us. Tron devs didn't know the Hive codebase at all, so they had to use the code that we wrote to freeze the Steemit Inc accounts in order to do that same thing right back to us. Talk about Karma, eh?
If I recall correctly, it only takes 4 or 5 dissenting witnesses to cancel a block and roll back the chain, so this made things really awkward during the hostile takeover.
Blast from the past:
@edicted/wow-17586-block-difference-between-steem-and-hive
Can't believe I finally found this post...
This shows how Steem missed 17586 blocks within the first two months of the Hive fork because of all the fuckery that went down.
@edicted/softfork-22-8888-you-can-t-make-this-shit-up
So many awesome people lost so much money to this bullshit, and the court case is still happening to this day. This list was greatly expanded to other accounts shortly after, including @theycallmedan and whales that never even participated in the bullshit and were just sitting idle the whole time. Truly fucked up, fam!
@inertia/theory-how-to-side-step-soft-consensus
Here's an interesting post by @inertia that kinda details what we were going through at that time, trying to sidestep the rollbacks and reclaim control of our own money.
But now I'm way off topic.
I thought this was supposed to be about RCs!
Yeah so witnesses can allow users who don't have enough RCs to post operations even if they don't have the gas to do so. It sounds weird, but it's true. That's because RCs are akin to virtual transactions and don't actually appear inside the blocks on the chain in any way. Rather, all the nodes separately track how many RCs each account has.
Does that mean RCs are second layer tokens?
If they aren't on the blockchain, that means they are second-layer, right? Well, how do we define second layer consensus? I define it as a centralized node or a group of nodes outside the consensus witnesses that use custom JSON operations on Hive to create new rules permissionlessly.
Under this definition, RCs are not second-layer tokens, because even though they do not exist inside the blocks, the Hive nodes themselves are still tracking and validating this information, just like blog-post rewards and account balances and everything else.
Just because RCs are somewhat optional and account balances can go negative doesn't mean they aren't on layer one. But they are definitely a very weird asset when we actually look at them under a microscope. It's weird to think that balances on a blockchain are allowed to go negative by design. In other contexts this would render a currency completely worthless if accounts were allowed to go negative. Luckily this is just our bandwidth resource we are talking about, and bandwidth is pretty abundant at this point, even though we run the entire network on 56k modem speeds (22KB/sec).
That being said, if bandwidth becomes a serious issue on Hive, there's nothing stopping witnesses from rolling back blocks that allow accounts to have negative RCs. This just isn't a problem right now so it's not really a priority. Such is reactive development and growth. I mean honestly maybe this is just a non sequitur in the first place because how many witnesses are even going to allow users to post to chain without RCs? I just think it's interesting that this is an option in the first place, which is why I mention it.
Conclusion
Resource credits, like virtual transactions, are a very weird concept. The information isn't in the blocks, which is logistically strange because we call it a "blockchain". The only information in the blocks are the operations that need to be signed by an actual person. All the other features are implied by inherent consensus and calculated independently across all nodes without the nodes ever needing to talk to each other to confirm the information. They're all running the same code, thus they all come to the same conclusion.
This is why every block on the blockchain must be stored by a node and replayed from the beginning. It is this replay mechanic that allows the nodes/servers to populate all the database information without actually needing to share that information with anyone else. All nodes calculate the info by themselves, and they all reach the same outcome. If anyone tries to cheat, the chain is rolled back a few blocks and we try again.
Final thought: blockchains are very weird.
Hive rules and Justin Sun drools.