stacks-network / stacks-core

The Stacks blockchain implementation
https://docs.stacks.co
GNU General Public License v3.0
3.01k stars 667 forks source link

Stacks-Inspect try-mine does not give an accurate projection of a mined block #3491

Open TensionCoding opened 1 year ago

TensionCoding commented 1 year ago

Describe the bug As part of the Stacks Foundation Grant, I have been working on a mempool explorer akin to mempool.space. Because of the nature of the Stacks blockchain, I cannot algorithmically simulate a mined Stacks block without executing / deploying smart contracts and contract calls which have to be processed by a Stacks node at runtime. Essentially, I need to ask a node to "mine." After opening an issue in stacks-blockchain-api repo concerning execution costs of mempool transactions, I was directed to stack-inspect by @obycode (awesome help by the way). @zone117x also suggested I open this issue in this repo.

I am aware that stacks-inspect is being constantly developed. Here are some of the issues I have found in regards to stacks-inspect: Faster L1 Working Group Issue #3313 Issue #3193

Here is the bug. I have been running stacks-inspect simulations on a consistent basis. It common to see simulations that return only one mined tx (a coinbase) and other times a series of simulations will consistently get bigger then start shrinking for no apparent reason. The simulations are inconsistent. My hope is to serve the projection to the website so that users can see if their transaction will be included in the next block. Here is an example of one of the projections being served to my dev site: Screenshot 2023-01-12 at 11 16 35 AM

Simulations:

Currently 147 tx in mempool. Simulation 1, 4 valid transactions. These simulations are being run continuously.

Screenshot 2023-01-13 at 10 12 06 AM

Simulation 2, 3 valid transaction. Screenshot 2023-01-13 at 10 13 37 AM

Simulation 3, 47 valid transactions Screenshot 2023-01-13 at 10 14 34 AM Screenshot 2023-01-13 at 10 14 41 AM

Simulation 4, 4 valid transactions Screenshot 2023-01-13 at 10 15 39 AM

Simulation 4, 54 valid transactions Screenshot 2023-01-13 at 10 16 20 AM Screenshot 2023-01-13 at 10 16 26 AM

Even though the previous projection included 54 transactions. The leader for block height 91103 only included 17 transactions in the main block and 6 in the microblock.

Simulation 5, 20 seconds later, 1 transaction (coinbase). A block was mined in between simulation 4 and 5 at height 91104 Screenshot 2023-01-13 at 10 17 47 AM

Currently 162 txs in mempool. These simulations are being run almost continuously and we can see a fluctuation in valid transactions. Screenshot 2023-01-13 at 10 25 33 AM

Screenshot 2023-01-13 at 10 25 56 AM

Screenshot 2023-01-13 at 10 26 47 AM

Screenshot 2023-01-13 at 10 27 37 AM

My final simulation before Block 91105 was mined

Three transactions, where in actuality Block 91105 included 60 txs in the main block.

Screenshot 2023-01-13 at 10 34 36 AM

Steps To Reproduce In the stacks-blockchain directory run cargo run --bin stacks-inspect try-mine path/to/mainnet/ 10 30000 During subsequent runs, run target/debug/stacks-inspect try-mine path/to/mainnet/ 10 30000. Also, it seems at this point 30000 or 60000 has no discernable effect on whether the mining simulation will spend more time iterating through tx candidates.

Expected behavior

try-mine will iterate through valid mempool transactions and produce a accurate projection of the next mined Stacks block

Environment (please complete the following information):

obycode commented 1 year ago

My suspicion on this one is that the changes you are seeing are related to micro-blocks being created. Since both the chain is live, with new micro-blocks coming in, and the mempool is live, with new transactions coming in, it is not surprising that you will see different results when running this tool multiple times.

I believe the solution here will be to provide more information that would help explain what is going on.