RE: Monitor Witness - Know your backup witness has failed before you depend on it
You are viewing a single comment's thread:
Thanks, looks handy. :)
As i‘m still learning the details of hive i don’t understand how the network picks the witness? ( i guess „find consensus“ )
So lets say I broadcast a transaction, how does the network determines which witnesses can add the next block?
Do you know were i can find this kind of information? Can also be on Code Level if you happen to know.
0
0
0.000
The top 20 witnesses take turns every block, then a shuffle is made for a backup witness in the 21st spot based on their rank.
It looks on the witness schedule.
https://hive.io
Since you've asked about witness schedule I'll shamelessly link my old article where you can find some information. The actual code that compiles future witness schedule starts here (follow to definition of
update_witness_schedule4), but of course the data it uses is updated all over the place.Thank you for sharing that valuable information and providing a link. It's exactly what I was searching for. Finding this kind of information, especially with the correct code examples and implementations, can be quite challenging.
I believe today is my lucky day as @edicted shared this post: https://peakd.com/hive-167922/@edicted/privex-hive-node-in-a-box-experience. It contains some really good information as well.
May I ask you something? I inquired with ChatGPT about consensus on the Hive blockchain and received this response. It appears to be quite accurate to me. Do you agree, or do you see any flaws in it?
Consensus:
In the Hive blockchain, the process of reaching consensus is a crucial step that ensures the validity and finality of a newly produced block. This consensus is achieved through the collaboration of various network participants, including the active witnesses and other nodes in the network. Here's how it works:
Broadcasted Block: After a witness produces a block, it is broadcasted to the Hive network. This block contains a collection of transactions that have been validated by the producing witness.
Relayed to Network: The block is propagated across the network to all other witnesses, full nodes, and participants in the Hive ecosystem.
Validation by Other Witnesses: Upon receiving the block, other witnesses, including those who are currently active and those in the backup positions, validate the transactions within the block. They check that the transactions comply with the Hive blockchain's consensus rules, that the sender has the required balance, and that there are no double-spending attempts.
Consensus Process: Witnesses and network participants then engage in a consensus process to determine the validity of the block. This process involves their nodes communicating with each other. Each participant verifies that the transactions within the block are valid and follow the established rules.
Acceptance or Rejection: If the majority of witnesses and nodes reach a consensus that the block is valid, it is accepted, and the transactions within it are considered confirmed and added to the blockchain. If there is a discrepancy or a significant portion of participants deems the block as invalid, it is rejected.
Finalization: Once consensus is reached, and the block is accepted, it is considered finalized. The transactions within the block are now an integral part of the Hive blockchain and are irreversible.
That description is far too broad. It shows that ChatGPT knows very little specific to the Hive other than that it is a cryptocurrency, since the description fits pretty much any blockchain. The sentence about "required balance" and "no double-spending attempts" in particular exemplify the problem - transfers, where that sentence fits, are only tiny portion of what is happening on Hive.
The true description that would be Hive specific should include topics such as: