Image by @dozeThis is not an expert information or educational material on Hive blockchain. This is just an observation by an ordinary participant of the Hive economy and an amateur coder trying to understand Hive blocks. I will be using python and Beem library by @holger80 for this exploration.
I start with the following python code that gets the last block number, gets the latest block, converts into a dictionary format and prints the contents of the block.
from beem import Hive
from beem.nodelist import NodeList
from beem.instance import set_shared_blockchain_instance
from beem.blockchain import Blockchain
from beem.block import Block
from pprint import pprint
nodelist = NodeList()
nodelist.update_nodes()
nodes = nodelist.get_hive_nodes()
hive = Hive(node=nodes)
set_shared_blockchain_instance(hive)
bc = Blockchain()
cbn = bc.get_current_block_num()
block = Block(cbn)
block = dict(block)
pprint(block)
The code returns key/value pair information about the block itself and transactions stored within the block. By running a for loop we can get what kind of items or information is stored in each block. Here is the list of 11 items that each block stores:
idblock_idprevioustimestampextensionswitnesswitness_signaturesigning_keytransaction_merkle_roottransaction_idstransactions
The most interesting item in the above list is transactions, that is where all the transactions like asset transfers, posts, comments, votes, etc are stored. We will explore transactions in more details later. Rest of the items are information about the block itself. If we remove transactions and transaction_ids from the block, the result would look like this:
id represents the block number. block_id looks like a unique alphanumeric id for the block. previous is a block_id of the previous block. Is this how chaining blocks happen, by including a reference to the previous block? Not sure, but that would be my guess. Then we have witness related information.
witness provides the name of the witness who produced the block. witness_signature how the block producing witness signs the block. And the signing_key is a public witness key. Interesting to note that average users who are not witnesses don't have this key. There are normally owner, active, posting, memo keys. But for witnesses looks like there is an additional key for signing blocks.
Two I items I have no clue about are the extensions and transactions_merkle_root. extensions appear in each block and looks like suppose to have an array/list of data in it. But it always appears to be empty. This is what google says about merkle root:
A merkle root is created by hashing together pairs of TXID s, which gives you a short yet unique fingerprint for all the transactions in a block. This merkle root is then used as a field in a block header, which means that every block header will have a short representation of every transaction inside the block.
That sort of explains the purpose of transactions_merkle_root.
My favorite one is timestamp, provides the date and time the block was produced. HIve blocks timestamp use UTC timezone. Each block is produced 3 seconds apart. However, I noticed sometimes there is 6 seconds difference between block timestamps. My guess for this is that sometimes witnesses miss blocks and when that happens the time difference between blocks is higher than 3 seconds.
The reason timestamp is my favorite because the blockchain uses its internal clock to stamp each block and prevents unexpected actions like double spending, provide transparency and security, and keep the integrity of the chain intact.
transaction_ids stores the list of unique transactoin ids for each transaction stored in the transactions. The following image shows an example of how a list of transaction_ids look like.
transactions is the most interesting compartment of each block. This is where all transactions are stored, and takes up the most space in a block. It contains a list of transactions and each transactions has the following data within them.
ref_block_numref_block_prefixexpirationextensionssignaturesoperations
The main content of the transaction is stored in operations, and rest of the items seems to store information about the transaction itself. I really don't understand how ref_block_num and ref_block_prefix numbers are generated. One thing I noticed though is that ref_block_num never goes higher than 65536 and when it gets that high it starts again from 1. We have extensions again that appear to be an empty array in each transaction. I would guess signature is signed by an account executing the transaction. The expiration stores date and time info like timestamp but the time is in the future. So, my guess is that transaction will expire if not put in a block and produced within the provided time.
Lastly, operations is where all the fun stuff is happening.
operations contains a list of operations. In theory, it seems we can store multiple operations here. However, it looks like there is only one operation stored here most of the time. I explored multiple blocks, and yet to see where there were multiple operations were bundled together within operations.
Each operation has two items: type and value. The way the value data is stored depends on the type of the operations. I wrote a script to go through last 100000 blocks to get the list of unique operation types. Following is the list of operation types I came up with:
custom_json_operationvote_operationtransfer_operationcomment_operationclaim_reward_balance_operationfeed_publish_operationlimit_order_create_operationlimit_order_cancel_operationwitness_set_properties_operationclaim_account_operationcreate_claimed_account_operationaccount_update_operationaccount_update2_operationaccount_witness_vote_operationtransfer_to_vesting_operationdelegate_vesting_shares_operationconvert_operationtransfer_to_savings_operationaccount_witness_proxy_operationdelete_comment_operationwithdraw_vesting_operationupdate_proposal_votes_operation
There probably are more operations that can be done Hive. They all are self-explanatory. Most common ones we use on daily basis are the vote, comment, transfer, claim_reward_balance operations. The most used operation it seems is the custom_json_operation. If you play games like Spliterlands, you can see those operations stored in a special custom_json_operation. This is probably one of the most powerful features of Hive blockchain to provide for developers of Apps and Games with ability to store and retrieve their data easily on the blockchain.
Feel free to correct me if I made mistakes or wrong assumption about certain parts of the blocks and feel free to share about things I have no clue about yet. Thanks!