Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

About irreversible block do not increase. Very incredibling! #6409

Closed
anlebcoder opened this issue Nov 28, 2018 · 6 comments
Closed

About irreversible block do not increase. Very incredibling! #6409

anlebcoder opened this issue Nov 28, 2018 · 6 comments
Labels

Comments

@anlebcoder
Copy link

Hi,EOS TEAM:

When BP died(<2/3), the irreversible height did not increase for a period of time. For example, stop for 10 minutes

Ten minutes later, we revived BP(>2/3) and the irreversible height began to grow.

You'll find that we're here(on_applied_irreversible_block) to find that the irreversible heights are about 10 minutes slower to receive messages.

my->irreversible_block_connection.emplace(
chain.irreversible_block.connect( [&]( const chain::block_state_ptr& bs ) {
my->applied_irreversible_block( bs );
} ));
why? It's incredible.

@jgiszczak
Copy link
Contributor

You seem to be asserting that one node of your testnet is increasing the last irreversible block, but 10 minutes after the other nodes increase it to the same height. I can assure you, whatever you are seeing, that's not what's happening. The software does not work that way. A producer network with 10 minutes of latency is not functional and will not advance the last irreversible block at all.

Please attempt a different description of what you are seeing, as I am sure my interpretation must not be correct.

@anlebcoder
Copy link
Author

anlebcoder commented Nov 29, 2018

@jgiszczak

Hello, maybe I didn't express it clearly.

I think the main network has this problem now

When the whole network survives less than two-thirds of the nodes, you will find that the irreversible height will stop growing, but the reversible height will increase.

After this state lasts for 10 minutes, if you restore the node to more than two-thirds, then you will find that the irreversible height starts to increase again.

Then there is the phenomenon I explained above, you will find

The log output on the screen is similar to this:

2018-11-29T03:52:14.031 thread-1 producer_plugin.cpp:332 on_incoming_block ] Received block a6c6c7803f6cbfb3... #15918315 @ 2018-11-29T03:52:14.000 signed by eosteaeostea [trxs: 0, lib: 15917986, conf : 0, latency: 31 ms]

#15918315 is Reversible height,
Lib:15917986 is irreversible height.

They differ by more than 300 pieces, why are there more than 300 pieces, I am very clear about the principle.

(2 * 21 * (2/3) * 12 = 360 )

Then the problem comes, we see that the output in the log is 15917986 - 15918315 = 329, this is the correct expectation.

In addition get_info is also the correct result, but you will find out if the code outputs irreversible height information:

 My->irreversible_block_connection.emplace(
               Chain.irreversible_block.connect( [&]( const chain::block_state_ptr& bs ) {
                  My->applied_irreversible_block( bs );
               } ));

This irreversible news was 10 minutes late. The normal situation is up to 180 seconds (360/2).

@redjade
Copy link
Contributor

redjade commented Nov 29, 2018

When 1/3 of BPs are down, DPOS irreversible block number doesn't increase. It's by design currently. See below.

return blocknums[ (blocknums.size()-1) / 3 ];

@wanderingbort
Copy link
Contributor

Hi @anlebcoder

You are correct there is bug affecting the issuing of the irreversible_block signal which will cause it to lag actual finality. As you've noted get_info will report the correct answer and there is no situation where the block reported as final by get_info will not eventually emit the signal.

We plan on addressing this in an upcoming audit/refactor of our fork database code. @arhag has more information. We should leave this issue open until an issue for that refactor is present and can reference it.

As for the math for blocks between the HEAD of reversible and the LIB, there is an offset in here due to the 12 blocks per producer. In the nominal case, the first block issued from producer, will add a unique confirmation for all blocks from the previous producers' rounds.

this means that the the delta on the first block of a set of 12 from HEAD to LIB should be
(13 * 12 + 1) + (12 * 14) === 325
|-----X-----|...|---Y---|

where X is the distance from HEAD to the Most confirmed block: that block carries its own producer as a commitment, 13 producers with 12 blocks each, and a single block from the final producer for a total of 15 commitments.

and Y is the distance from that confirmed block to the first double-confirmed (aka irreversible) block. that block carries its own commitment and 14 additional producers with 12 blocks.

at the end of current producers round of 12, there will be 11 more blocks but no additional unique commitments. Therefore, over the course of a producers round, the distance to LIB in a nominal network should start at 325 and go to 336.

@anlebcoder
Copy link
Author

anlebcoder commented Dec 3, 2018

@wanderingbort tks, I think mongo Plugin maybe also not correct. OAH~

@licao
Copy link

licao commented Dec 5, 2018

Hi,EOS TEAM:

When BP died(<2/3), the irreversible height did not increase for a period of time. For example, stop for 10 minutes

Ten minutes later, we revived BP(>2/3) and the irreversible height began to grow.

You'll find that we're here(on_applied_irreversible_block) to find that the irreversible heights are about 10 minutes slower to receive messages.

my->irreversible_block_connection.emplace(
chain.irreversible_block.connect( [&]( const chain::block_state_ptr& bs ) {
my->applied_irreversible_block( bs );
} ));
why? It's incredible.

what ,enjoy yourself~

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants