Skip to content

Conversation

@SozinM
Copy link
Collaborator

@SozinM SozinM commented Oct 24, 2025

πŸ“ Summary

πŸ’‘ Motivation and Context


βœ… I have completed the following steps:

  • Run make lint
  • Run make test
  • Added tests (if applicable)


/// The arena in which multiple [`FlashblockCandidate`] are competing for a specific flashblock interval batch.
/// It contains context of the building job, and shared precomputed elements that are required in each candidate.
struct BatchArena {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather keep it more lean, have best_flashblock variable, implement Ord for FlashblockPayload

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or custom function for comparison

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see but best_flashblock will have multiple fields (new_payload, fb_payload)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

) -> eyre::Result<FlashblockCandidate> {
// Collect candidate best txs without updates
// This is not using best_txn to be able to bound number of txs to execute and collect them, so we need to remove commited txs
let candidate_best_txs: Vec<Arc<ValidPoolTransaction<Pool::Transaction>>> = self
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use BestTransactionIterator wrapper we use in current code

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't directly used it to be able to first collect all best transactions in a vec, so the iterator is consumed at once and not updated anymore. It allows to allocate correctly execution info size and then only update main BestTransactionIterator best_txns after.
I could potentially modify a bit BestTransactionIterator to make it works similarly.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

};

// build block
let build_result = build_block(
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's interesting piece, ideally i don't want to seal block until we spent enough time builder flashblocks
So we should somehow determine how good flashblocks is without this, i suggest using cumulative_gas for flashblocks, or something like this

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or i would be coinbase profit + gas used

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But as the same time we don't want to build it too late so that when interval is reached we can send best as soon as possible

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used execution info after executing txns and only build block if the cumulative gas is greater than previous best.

@julio4 julio4 force-pushed the feat/continuous-block-building branch from 338886f to 8b3ac6a Compare October 27, 2025 02:30
@julio4 julio4 force-pushed the feat/continuous-block-building branch from 8b3ac6a to c0371dc Compare October 27, 2025 07:07
@julio4
Copy link
Collaborator

julio4 commented Nov 3, 2025

To close in favor of #311

@SozinM SozinM closed this Nov 3, 2025
@julio4 julio4 deleted the feat/continuous-block-building branch November 4, 2025 05:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants