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

Supplement baseFee and gasLimit for pre gingerbread blocks #302

Open
wants to merge 15 commits into
base: celo11
Choose a base branch
from

Conversation

Kourin1996
Copy link

Closes https://github.com/celo-org/celo-blockchain-planning/issues/384

This PR adds baseFeePerGas and gasLimit to the response of pre Gingerbread block in JSON-RPC

@Kourin1996 Kourin1996 self-assigned this Dec 20, 2024
@Kourin1996 Kourin1996 marked this pull request as ready for review January 6, 2025 11:30
@palango palango requested a review from piersy January 8, 2025 09:08
internal/ethapi/celo_block.go Outdated Show resolved Hide resolved
internal/ethapi/celo_block.go Outdated Show resolved Hide resolved
internal/ethapi/celo_block.go Show resolved Hide resolved
Copy link

@piersy piersy left a comment

Choose a reason for hiding this comment

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

Hi @Kourin1996, looks good overall, but I don't see a reason to store the gas limit in the database, when we have it hardcoded. So I would just store the base fee.

Also how did you get your benchmark results? https://github.com/celo-org/celo-blockchain-planning/issues/384#issuecomment-2553929355

t.Run(test.name, func(t *testing.T) {
for _, seed := range test.seedData {
err := db.Put(preGingerbreadAdditionalFieldsKey(seed.hash), seed.data)
assert.NoError(t, err)
Copy link

Choose a reason for hiding this comment

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

I would use require here instead of assert. A failed assert statement does not abort the test, whereas require will. In this case if the insertion fails then there is no reason to continue the test.

Copy link
Author

Choose a reason for hiding this comment

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

Learned new best practice! Thank you :) I will fix that

Copy link
Author

Choose a reason for hiding this comment

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

Most of assert.* have been replaced with require.*. Resolved the following related comments.

}

// retrievePreGingerbreadGasLimit retrieves a gas limit at given height from hardcoded values
func retrievePreGingerbreadGasLimit(backend CeloBackend, height *big.Int) *big.Int {
Copy link

Choose a reason for hiding this comment

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

Seems like this could take a chain config instance instead of the CeloBackend

Copy link
Author

Choose a reason for hiding this comment

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

Yes, I modified codes so that only base fee will be stored in DB at commit a67a0ad

@Kourin1996
Copy link
Author

@piersy

Also how did you get your benchmark results? https://github.com/celo-org/celo-blockchain-planning/issues/384#issuecomment-2553929355

Set up a local cluster using simple-celo-node, but create a new Dockerfile under op-geth.
After run scripts to send JSON-RPC requests of eth_getBlockByNumber over a million blocks. Record the average response time using two types of codebases: (1) Retrieving gasPrice with each request and (2) Loading data from local database first, and retrieving gasPrice from the receipt only if the record does not exist

@Kourin1996 Kourin1996 requested review from piersy and palango January 10, 2025 11:41
@palango
Copy link

palango commented Jan 10, 2025

Question regarding the general approach: we could also do those calculations during the migration right. That would trade some complexity there for simpler code in the codebase. Any opinions on that?

@piersy
Copy link

piersy commented Jan 10, 2025

Question regarding the general approach: we could also do those calculations during the migration right. That would trade some complexity there for simpler code in the codebase. Any opinions on that?

The problem with that approach is that we are not syncing this data, so if we did that, snap sync nodes would not have it. So I think it's better to calculate it on demand as it is done here.

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.

3 participants