This 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:
id
block_id
previous
timestamp
extensions
witness
witness_signature
signing_key
transaction_merkle_root
transaction_ids
transactions
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_num
ref_block_prefix
expiration
extensions
signatures
operations
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_operation
vote_operation
transfer_operation
comment_operation
claim_reward_balance_operation
feed_publish_operation
limit_order_create_operation
limit_order_cancel_operation
witness_set_properties_operation
claim_account_operation
create_claimed_account_operation
account_update_operation
account_update2_operation
account_witness_vote_operation
transfer_to_vesting_operation
delegate_vesting_shares_operation
convert_operation
transfer_to_savings_operation
account_witness_proxy_operation
delete_comment_operation
withdraw_vesting_operation
update_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!
Posted Using LeoFinance
Someone who knows what they are talking about:
https://leofinance.io/steem/@xeroc/steem-transaction-signing-in-a-nutshell
This is to stop someone from using a very old block number. They don't want people to sign a transaction using an old block... because if their was a fork a hacker would be able to rebroadcast the public transaction on the other chain.
Me:
https://peakd.com/hextech/@edicted/the-day-of-milestones
Posted Using LeoFinance
Awesome! Thank you for sharing the posts on this and explaining why and how ref_block_num and ref_block_reference work. Very helpful. I will study the posts more.
Posted Using LeoFinance
My python skillzz might become useful soon
Posted Using LeoFinance
Your skillz are impressive!
Posted Using LeoFinance
The
extensions
used to store the running version ofsteemd
that signed the block, as well as the upcoming hardforks that a witness has accepted (if any). But since HF23 this information is no longer present.This is the first block that I signed on the chain which recorded v0.22.1, and the last block that I signed on Steem, which shows that I accepted HF23 at a particular timestamp.
There are more than 50 different operations on Hive, which can be found here. Some of them were depreciated in previous hardforks, such as creating an account with delegation.
Thank you for sharing. These are very useful. Do you know what
extensions
inside of transactions for?That operations list is great. Thanks. It even has virtual operations. Something I was going to look at next.
For some reason they are meant to be empty
https://gitlab.syncad.com/hive/hive/-/blob/master/libraries/plugins/apis/condenser_api/include/hive/plugins/condenser_api/condenser_api_legacy_objects.hpp#L39
Anyone who’s interested in exploring hive blocks may enjoy this visualization. It streams Hive blocks and visualizes their contents, including identifying the apps in custom JSON operations.
https://hiveuprss.github.io/hiveisbeautiful/
This is pretty cool tool! Where can I see the code?
Posted Using LeoFinance
Hey! The code is here: https://github.com/hiveuprss/hiveuprss.github.io/tree/master/hiveisbeautiful
Nice! Thank you!
HIVE.D!