Why not just make them operations like everything else?
Apparently virtual operations are ops that don't require a signature from users on the network. They are essentially operations that the blockchain authorizes itself as part of consensus. Whenever you get a payout, that is the network agreeing that you get the payout; no one has to authorize this event, it just happens.
This has some interesting implications. Virtual ops are basically ones that the blockchain makes of its own accord, almost like it is a living breathing entity. All nodes are in consensus as to which virtual ops the network will create, so these operations are never broadcast between nodes. Instead, it is simply assumed that the nodes will generate them locally and update the state of the database accordingly without anyone having to agree on them in real time.
https://github.com/steemit/steem/issues/146
Here we see GitHub issue 146 as it pertains to Steem, all the way back from July 2016, only 3 months after launch.
Make virtual operations accessible over the RPC endpoint #146
I don't know how to watch for these operations happening on the blockchain.
So, would it be possible to somehow make these virtual operations visible as they are happening?
The get_account_history call in database_api returns the operation history of a specific account, virtual operations included.
There is not currently a way to get the full stream of virtual ops over the RPC endpoint.
Can you imagine creating a blockchain and then booting up a full node that doesn't give anyone access to some of the most important operations happening on chain? Operations like, oh I don't know, every bit of inflation created on the network. Well imagine no further! For that blockchain was Steem in 2016. We've come a long way since then, but not far enough imo.
mvandeberg commented on Aug 3, 2017
get_ops_in_blockadded in #649 can return virtual ops.
It took over a year to create this full on hackish solution. Even to this day there is no way to query the full node API to get all the block information in a single request. You have to ask for the block and the virtual operations of that block separately. Yikes.
My witness partner 
<script src="https://unpkg.com/dsteem@^0.10.0/dist/dsteem.js"></script>
<script>
let client = new dsteem.Client('https://' + 'anyx.io')
client.blockchain.getCurrentBlockNum(1).then((head_blocknum) => {
let blocknum = head_blocknum - 21
console.log(blocknum);
client.database.call('get_ops_in_block',
[blocknum, true]).then(function(operations){
console.log(operations);
})
})
</script>
This script can be run from your browser if saved in an .html file.
F12 to open console.
On the line that says let blocknum = head_blocknum - 21, if you change that 21 to a lower number like 10 or less the node will return an empty list with no information. Now is another good time to make a dig at Condenser and ask why it doesn't just wait for the virtual ops to get created instead of sending you a worthless empty array? Because reasons.
Because virtual ops do not get generated until a minute after the block was created, this means they have nothing to do with witness signatures and they are never even broadcast to the rest of the network. All nodes simply divine exactly every one that needs to be created once the block becomes immutable. So weird, but it makes sense. No reason to unnecessarily burden an already inefficiently redundant network.
Every block has at least one virtual op once it becomes immutable. This, of course, is the block producer_reward that gets paid out to the witness for creating the block. If you were to test out my script above, you'd see that most blocks actually only have this virtual op and no others.
From there, the next likely virtual op you'd run into is curation. There are obviously a lot more curation rewards than author rewards (because their are more votes than content) but at the same time every curation reward must also be linked to an associated author reward, and they are both paid out on the same block. Obviously, it's impossible to curate content that didn't receive rewards.
While inspecting random blocks, I also came across a fill_order operation, which is where HBD is traded for Hive on the internal market. fill_vesting_withdraw is when money becomes unlocked due to a powerdown while fill_convert_request is when HBD gets destroyed and creates $1 worth of Hive 3.5 days later. As you might imagine, these virtual operations are much more rare than the initially mentioned ones.
I've been here three years and I'm still learning stuff.
Pretty crazy.
Virtual operations are an extremely important aspect of the network. Our consensus depends on it. This is especially true considering all nodes depend on each other to generate network inflation and distribute it precisely down to 0.001 Hive. Two or more nodes having conflicting values could lead to catastrophic effects (unintended forks and consensus issues) months after the mistake was made because the error would not happen until someone tried to transfer money that didn't exist on other nodes.
This information is extremely relevant to me because I've always had the idea for a curation bot and reputation system on the back-burner. Hopefully this increased understanding of the network will help myself and anyone else looking for that additional clarity.
