Topic: A new type of consensus protocol - page 2. (Read 310 times)

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;
The new way of mining competition helps change the environment of App or website development and improve the user experience.

Hi every one:

Here is a new type of consensus protocol that might help resolve some

common problems of POW and POS:

disabled

And there are some draft project plans based on the protocol.

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)
disabled