Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: Replace Class Hash issue resolved, gas fees bug resolved, cap removed for pending tick #409

Merged
merged 26 commits into from
Dec 23, 2024

Conversation

Mohiiit
Copy link
Contributor

@Mohiiit Mohiiit commented Dec 9, 2024

  • Gas fees bug resolved.
  • Replace class hash bug resolved
  • Cap removed for pending tick

Pull Request type

  • Bugfix
  • Feature

What is the current behavior?

  • In gas fees bug, it was disabling fee setting of eth when strk prices are defined in the arguments.
  • Replace class issue occurs because we are saving the class hash in the db when a contract is declared, and while checking whether the class hash of the deployed contract already exist, it returns true even tho it's the first time the contract is being deployed.
  • Currently there is a cap on number of steps/gas a tick can consume, in ideal case the block should be close either when the limit is reached or when the block time is over.

Resolves: #NA

What is the new behavior?

  • gas fees is resolved by disabling the strk prices when it's defined in the args.
  • for replace class hash issue, now we check whether the class hash of the deployed contract matches with the one stored in the db, if it matches then it means it's not replaced.
  • cap is removed, blockifier returns whether the limit for the block is reached or not, we are using that flag to close the block early.

Does this introduce a breaking change?

No

@Mohiiit Mohiiit marked this pull request as draft December 9, 2024 11:00
@Mohiiit Mohiiit marked this pull request as ready for review December 9, 2024 11:44
Copy link
Collaborator

@Trantorian1 Trantorian1 left a comment

Choose a reason for hiding this comment

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

Some aspects of this pr seem a bit strange to me and might need some tidying up.

configs/presets/devnet.yaml Outdated Show resolved Hide resolved
configs/presets/devnet.yaml Outdated Show resolved Hide resolved
crates/client/block_production/src/lib.rs Outdated Show resolved Hide resolved
crates/client/devnet/src/lib.rs Show resolved Hide resolved
crates/client/devnet/src/lib.rs Show resolved Hide resolved
crates/client/devnet/src/lib.rs Show resolved Hide resolved
crates/client/devnet/src/lib.rs Show resolved Hide resolved
crates/client/devnet/src/lib.rs Show resolved Hide resolved
crates/client/mempool/src/l1.rs Outdated Show resolved Hide resolved
crates/client/devnet/src/lib.rs Show resolved Hide resolved
crates/client/mempool/src/l1.rs Outdated Show resolved Hide resolved
@@ -77,6 +77,15 @@ pub enum Error {
#[error("State diff error when continuing the pending block: {0:#}")]
PendingStateDiff(#[from] StateDiffToStateMapError),
}

struct ContinueBlockResult {
Copy link
Member

Choose a reason for hiding this comment

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

could you document this struct for rust doc?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added

Copy link
Member

@antiyro antiyro left a comment

Choose a reason for hiding this comment

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

lgtm

Copy link
Member

@cchudant cchudant left a comment

Choose a reason for hiding this comment

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

i think you should also reset the intervals in block_production_task when a block is closed,

interval_pending_block_update.reset_at(instant + interval_pending_block_update.period());
interval_block_time.reset_at(instant + interval_block_time.period());

@@ -353,8 +351,13 @@ impl<Mempool: MempoolProvider> BlockProductionTask<Mempool> {

Copy link
Member

Choose a reason for hiding this comment

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

i think you should split the on_block_time function in two: on_block_time and close_block and on_pending_block_tick should call close_block instead of on_block_time

Copy link
Contributor Author

Choose a reason for hiding this comment

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

did something very similar, lmk wdyt?

interval_pending_block_update.reset_at(instant + interval_pending_block_update.period());
interval_block_time.reset_at(instant + interval_block_time.period());
}
self.current_pending_tick += 1;
Copy link
Member

Choose a reason for hiding this comment

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

could you reset the current_pending_tick to 0 as well?
(i believe the current pending tick variable is now useless, is that the case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah I thought about it as well, pushing the changes that I think made sense, lmk wdyt

Copy link
Member

@cchudant cchudant left a comment

Choose a reason for hiding this comment

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

yes :)

@antiyro antiyro merged commit 34d629c into main Dec 23, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants