Topic: A new type of consensus protocol (Read 142 times)

Figure 2: Process of block generation vote and validation
As shown in the scheme above, the system will count votes in certain existing blocks and the honeycomb with maximum votes can have the highest chance to win the competition.


Figure 3: Process of main chain vote and validation
As shown in the scheme above, whenever there is any fork, the transactions will also vote for the branch, which determines the number of votes (stakes) for different branches in the next voting, i.e. the amount of block generation difficulty parameter Y is determined. Thus, the more votes one branch can get, the faster it will be to generate the next block, and the faster broadcast is helpful to gain more votes in the next round. This process will increase the gap between these two branches and determine the main chain in short time.

Consensus Process

1. Before publishing a transaction, a Flower node will broadcast a signal to preannounce it. The Workers nearby send "Honey gather" requests back when they detect the signal.

2.After receiving the first request from a Worker, the Flower packs the main chain’s  tail-block "b" and the address "m" of the Honeycomb who owns the Worker into the transaction structure , and then broadcasts the transaction. A successful "Honey gathering" is completed.

3.This transaction is validated and packed into a new block by another miner, and then broadcasted in the network.

4. When a Honeycomb receives a new block, he begins to validate it. At the same time, the Honeycomb checks the field "b"f and "m" of each transaction. Mark the transactions with "x" when their "m" fields point at the Honeycomb himself and mark them with "y" when their "b" fields match the current chain’s tail-block.

5. Equally divide the balance of each Flower between all of its transactions in that block.

6. Add up the balances divided at the previous step of all the transactions marked with both "x" and "y" until the Honeycomb meets the target of generating a block. The result is denoted by "X" and the max number of statisticed blocks is 100.
 
7.Add up the divided balances of the transactions marked with "y" only in the current block and denote the result by "Y".

8.The Honeycomb is trying periodically to meet the target of generating a block with a mathematical operation based on constants such as timestamps and private signatures. That is denoted by: proofFunction() < target*d*X*Y, "d" means the difficulty adjustment parameter. Other blocks received during that process, competing for the main chain, should be parallel processed. In order not to weaken the main chain, dthere is no need to stop competing for the current chain if the weight of main chain is less than the existing chain plus eight, and it actually follows its own benefits (possible to main chain).

9.After meeting the target of generating a block, the Honeycomb packs all of the transactions received during this period into a new block and broadcasts it. All of the "xy" marked transactions (coded within 100 blocks in order to save some space), profits of all nodes and other parameters should also be packed for verification. Mining rewards will be distributed proportionally between miners and all the flower nodes marked with xy.


For better understanding, the steps can be briefed as
"Every time they publish a transaction, the stakeholders vote with their stake on the miners to generate a block and on the branches to be accepted as part of the main chain. The more stake a block or a miner get, the higher chance they win the competition."

The network scheme is shown as below:

Here are the summaries of this article:

Compared with "POW" and "POS", this model has the following benefits:
no hashpower competition and no high-energy-consumption;
 no "nothing at stake" and "stake grinding" attack;
optimize wealth distribution logic based on "stake" and replace all the inactive nodes with miners to maintain the network;
ensure the rewards are matchable with working load to facilitate the benign development of cryptocurrencies.

1.Flowers vote with their stakes and that can not be faked.
2.Honeycomb's work doesn't need to be verified. But I don't think I get what you mean.
3.

What if a Honeycomb has created network of Flowers accounts with fake network configuration, so that it appears very easy for him to gather?
How a Honeycomb's work can be verified when time passed and network configuration changed?

Also, what is the main selling point of this consensus algorithm, energy efficiency?

Hi every one:

Here is a new type of consensus protocol and some draft plans based on it.  

[disabled]

The translation is being worked on, I will update it as soon as possible.

Or you can read the Original Version

[disabled]

if it is possible.

I want to share them with you and hope to find someone interested.

Anyone who has any question, please let me know. Thanks!


Previous post(Chinese)
https://bitcointalksearch.org/topic/--3185546