search

nimiq / core-rs-albatross

Rust implementation of the Albatross protocol
https://nimiq.com
Other
159 stars 61 forks source link

Mempool: new_staker transactions becomes invalid when stake transaction creates a staker on the fly #1041

Closed redmaner closed 1 year ago

redmaner commented 2 years ago

New issue checklist

General information

Bug report

Expected behavior

Sending a new staker transaction should be handled correctly when producing blocks

Actual behavior

In rare occasions sending a new staker transaction will result in a panic in the client. This happens when a staker is created on the fly by a stake transaction for an account that is not a staker yet. Creating a staker by the stake transaction invalidates a create staker transaction that entered the mempool after the stake transaction. Applying the new staker transaction when it is already created by a preceding stake transaction on the fly causes a panic.

Steps to reproduce

On the devnet, for an account that is not a staker yet:

  • Send a stake transaction
  • Send a new staker transaction afterwards

This can also be reproduced by using albagen by checking out the chaos branch: https://github.com/redmaner/albatross_generator/tree/chaos

Crash log? Screenshots? Videos? Sample project?

Mutliple validators have logs of the panic in question.

viquezclaudio commented 2 years ago

Failing signature looks like this:

Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.592677Z DEBUG tendermint           | Voting succeeded in round 0, assembling block.
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.670804Z DEBUG push                 | Accepted block block=#6996000.0:MA:012b427972 num_transactions=0 kind="extend"
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.670877Z DEBUG push                 | Ignoring block block_no=6996000 reason="we have already finalized an earlier macro block" last_macro_block_no=6996000
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.671664Z DEBUG validator            | Initializing block producer next_block_number=6996001 next_view_number=0
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.672663Z DEBUG micro                | Not our turn, waiting for micro block #6996001.0 block_number=6996001 view_number=0 slot_band=3
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.762984Z DEBUG block_queue          | Received block via gossipsub block=#6996001.0:MI:1a092d6ef2
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.776902Z ERROR staker               | Couldn't find the staker to which a stake transaction was destined. Plan B: Create a new staker at this address!
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.851924Z DEBUG push                 | Accepted block block=#6996001.0:MI:1a092d6ef2 num_transactions=294 kind="extend"
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.854021Z DEBUG validator            | Initializing block producer next_block_number=6996002 next_view_number=0
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.855619Z INFO  micro                | Our turn, producing micro block #6996002.0 block_number=6996002 view_number=0 slot_band=3
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.855915Z DEBUG mempool              | Returned control transactions from mempool returned_txs=1 remaining_txs=0
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.856098Z DEBUG mempool              | Requesting regular txns and there are no txns in the mempool
Sep 17 15:27:28 validator4 nimiq-client[915669]: 2022-09-17T15:27:28.864891Z ERROR panic                | thread 'tokio-runtime-worker' panicked at 'Failed to compute accounts hash during block production: AlreadyExistentAddress { address: Address("f7ea9dd8d9cd37b92c6b7c4d9db6cb0f9bc6fc4e") }': block-production/src/lib.rs:84
jsdanielh commented 1 year ago

This is handled by failing transactions in #905.