stacks-network/stacks-core

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

Open

#3491 aperta il 13 gen 2023

Vedi su GitHub
 (1 commento) (0 reazioni) (1 assegnatario)Rust (758 fork)auto 404
help wantedicebox

Metriche repository

Star
 (3063 star)
Metriche merge PR
 (Metriche PR in attesa)

Descrizione

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

  • OS: Mac OS Ventura 13.0
  • Rust version: 1.66.0
  • Running git clone of stacks-blockchain master branch from last week.

Guida contributor