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

Reduce max gas limit per mini block #3475

Merged
merged 47 commits into from
Oct 8, 2021

Conversation

SebastianMarian
Copy link
Contributor

@SebastianMarian SebastianMarian commented Sep 28, 2021

  • Implemented gas limit calculation in cross mbs dest me taking into account also gas refunded
  • Implemented gas limit calculation in cross mbs dest me taking into account also gas penalized
  • Reduced max gas limit per cross shard mini block from me
  • Registered VM to gas schedule notifier

Testing scenario:

  1. Start a normal system test
  2. In epoch 2, OptimizeGasUsedInCrossMiniBlocks flag will be activated
  3. Start txgen from this branch and with this param:
    txgen branch: temp-increase-gas-erc20-esdt
    txgen starting command: ./start.sh start 100 base
  4. After 1-2 epochs we should check the logs for "gas consumed, refunded and penalized info" messages and we should have in some of them "total gas consumed" higher than 1.5 billion, but "total gas consumed" - "total gas refunded" - "total gas penalized" always lower than 1.5 billion.
  5. Also we should find messages like this "transactions.splitMiniBlockIfNeeded: gas limit exceeded" when mini blocks with gas higher than 500 mil. will be split and more mini blocks with lower gas

@SebastianMarian SebastianMarian added the type:feature New feature or request label Sep 28, 2021
@SebastianMarian SebastianMarian self-assigned this Sep 28, 2021
…-gas-limit-per-mini-block

# Conflicts:
#	process/block/preprocess/transactions.go
#	process/mock/gasHandlerMock.go
@codecov
Copy link

codecov bot commented Sep 29, 2021

Codecov Report

Merging #3475 (c880fe4) into development (b573b38) will increase coverage by 0.02%.
The diff coverage is 79.46%.

❗ Current head c880fe4 differs from pull request most recent head c6a21c7. Consider uploading reports for the commit c6a21c7 to get more accurate results
Impacted file tree graph

@@               Coverage Diff               @@
##           development    #3475      +/-   ##
===============================================
+ Coverage        73.85%   73.87%   +0.02%     
===============================================
  Files              581      581              
  Lines            73907    74193     +286     
===============================================
+ Hits             54583    54812     +229     
- Misses           14945    14993      +48     
- Partials          4379     4388       +9     
Impacted Files Coverage Δ
node/nodeRunner.go 0.00% <0.00%> (ø)
process/economics/testEconomicsData.go 0.00% <0.00%> (ø)
genesis/process/shardGenesisBlockCreator.go 43.09% <66.66%> (+0.15%) ⬆️
process/economics/economicsData.go 71.17% <69.29%> (-3.91%) ⬇️
process/block/preprocess/smartContractResults.go 69.75% <70.00%> (+1.00%) ⬆️
process/coordinator/process.go 75.06% <74.46%> (-0.07%) ⬇️
process/block/preprocess/transactions.go 55.69% <76.00%> (+2.55%) ⬆️
process/block/preprocess/basePreProcess.go 77.11% <88.63%> (+3.64%) ⬆️
process/block/postprocess/basePostProcess.go 78.90% <94.11%> (+3.70%) ⬆️
factory/blockProcessorCreator.go 80.33% <100.00%> (+0.10%) ⬆️
... and 9 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8d93b2b...c6a21c7. Read the comment docs.

# Conflicts:
#	cmd/node/config/enableEpochs.toml
#	config/epochConfig.go
#	config/tomlConfig_test.go
#	genesis/process/shardGenesisBlockCreator.go
#	integrationTests/testProcessorNode.go
#	node/nodeRunner.go
#	p2p/libp2p/discovery/continuousKadDhtDiscoverer.go
#	p2p/libp2p/discovery/optimizedKadDhtDiscoverer.go
#	process/smartContract/process.go
@SebastianMarian SebastianMarian changed the title [WIP] Reduce max gas limit per mini block Reduce max gas limit per mini block Sep 30, 2021
@SebastianMarian SebastianMarian marked this pull request as ready for review September 30, 2021 13:08
SebastianMarian and others added 5 commits October 3, 2021 22:12
# Conflicts:
#	factory/blockProcessorCreator.go
#	genesis/process/metaGenesisBlockCreator.go
#	genesis/process/shardGenesisBlockCreator.go
#	integrationTests/testProcessorNode.go
#	process/smartContract/process.go
@iulianpascalau iulianpascalau self-requested a review October 6, 2021 05:17
Copy link
Contributor

@iulianpascalau iulianpascalau left a comment

Choose a reason for hiding this comment

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

minor stuff

MaxGasLimitPerBlock = "1500000000"
MaxGasLimitPerMetaBlock = "15000000000"
GasLimitSettings = [
{EnableEpoch = 0, MaxGasLimitPerBlock = "1500000000", MaxGasLimitPerMiniBlock = "1500000000", MaxGasLimitPerMetaBlock = "15000000000", MaxGasLimitPerMetaMiniBlock = "15000000000", MinGasLimit = "50000"},
Copy link
Contributor

Choose a reason for hiding this comment

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

MaxGasLimitPerMetaMiniBlock = "15000000000" is this ok? It is a ok for the metachain to produce such a large miniblock? Who can consume this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the way it was worked until now. Gas per mini block = Gas per block = 1.5 bil. or 15 bil. in meta.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The difference is that nobody will create miniblocks with gas limit > 1.5 bil. gas, even if they are for meta. The max gas limit of 15 bil. is used only by meta, to accept in one created block, many miniblocks from different shards to himself, until the cumulative gas from each of them reached the 15 bil.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And the most important thing is to keep the backward compatibility, so the mini block gas limit should be equal with block gas limit until the activation epoch for this PR

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, but on the next line we have this: MaxGasLimitPerMetaMiniBlock = "5000000000" - 5 billion. How can we interpret this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

WIth the new version of MaxGasLimit configs, the max gas limit per mini blocks in shards and meta will be reduced at 30% from the value used in the first verison. In meta from 15 bil. to 5 bil. and in shards from 1.5 bil to 500 mil.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Anyway the concept of max gas limit per mini block in META does not have a real use case for now. Instead, max gas limit per block is used when a block is created, filled with stuff up to 15 bil. gas. The only use case of gas per mini block, either if the proposer is in shard or in meta, is when it creates a cross shard mini block and it takes into consideration the gas limit per mini block into receiver shard. Actually in this case the shard proposer theoretically could create a mini block to meta which consumes max 5 bil. gas in meta after the activation epoch. Until then the mini block could have even 15 bil. gas.

Copy link
Contributor

Choose a reason for hiding this comment

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

5 billion gas in meta in one miniblock.....that is very dangerous as it might stop the metachain. I think we should put the MaxGasLimitPerMetaBlock to the exact value of MaxGasLimitPerMiniBlock

epochStart/mock/economicsHandlerStub.go Outdated Show resolved Hide resolved
genesis/process/disabled/epochNotifier.go Outdated Show resolved Hide resolved
node/mock/txFeeHandlerStub.go Outdated Show resolved Hide resolved
process/common.go Outdated Show resolved Hide resolved
process/block/preprocess/transactions.go Show resolved Hide resolved
integrationTests/testProcessorNode.go Show resolved Hide resolved
conversionBase := 10
bitConversionSize := 64
for _, gasLimitSetting := range economics.FeeSettings.GasLimitSettings {
minGasLimit, err := strconv.ParseUint(gasLimitSetting.MinGasLimit, conversionBase, bitConversionSize)
Copy link
Contributor

Choose a reason for hiding this comment

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

duplicated code on L256-L279 with the setGasLimitSetting function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is different. This one is done in local variables just for checking the validity of the received parameters on New.. method, before the object is created. In setGasLimitSetting the convertion is done directly into members variables at epoch change. This conversion part could not be extracted into a single method which would satisfy both situations.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes because the code is written in such way. Could have been refactored as to have only one parse function. I will make a PR that refactors this exact part and you will be one of the reviewers :D

process/economics/economicsData.go Show resolved Hide resolved
process/economics/economicsData.go Outdated Show resolved Hide resolved
genesis/process/disabled/epochNotifier.go Outdated Show resolved Hide resolved
process/common.go Outdated Show resolved Hide resolved
@@ -976,6 +1026,7 @@ func (tc *transactionCoordinator) VerifyCreatedBlockTransactions(hdr data.Header
}(interimProc)
}

tc.mutInterimProcessors.RUnlock()
wg.Wait()
Copy link
Contributor

Choose a reason for hiding this comment

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

unlock should be after wg.Wait

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm, I just took the mechanism from one method above -> IsDataPreparedForProcessing. I have done the same thing also there.

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually the rlock - runlock is used only for the iteration. After the for loop is done, the mutex can be released. I've solved these kind of situation by having the locking held only to have a copy of the slice. Then, I could have iterated on the copied slice with no problems even if the locking was released.

process/block/preprocess/basePreProcess.go Outdated Show resolved Hide resolved
@@ -901,6 +914,12 @@ func (txs *transactions) createAndProcessMiniBlocksFromMe(
totalTimeUsedForComputeGasConsumed += elapsedTime
if err != nil {
log.Trace("createAndProcessMiniBlocksFromMe.computeGasConsumed", "error", err)
isTxTargetedForDeletion := errors.Is(err, process.ErrMaxGasLimitPerOneTxInReceiverShardIsReached)
Copy link
Contributor

Choose a reason for hiding this comment

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

we could add this at interceptor level as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

WIll be added in another PR. I already talked with @iulianpascalau about this earlier protection mechanism

process/block/preprocess/transactions.go Show resolved Hide resolved
process/coordinator/process.go Outdated Show resolved Hide resolved
@@ -976,6 +1026,7 @@ func (tc *transactionCoordinator) VerifyCreatedBlockTransactions(hdr data.Header
}(interimProc)
}

tc.mutInterimProcessors.RUnlock()
wg.Wait()
Copy link
Contributor

Choose a reason for hiding this comment

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

Actually the rlock - runlock is used only for the iteration. After the for loop is done, the mutex can be released. I've solved these kind of situation by having the locking held only to have a copy of the slice. Then, I could have iterated on the copied slice with no problems even if the locking was released.

wg.Wait()
tc.mutRequestedTxs.RUnlock()
Copy link
Contributor

Choose a reason for hiding this comment

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

this is a good change 👍

@@ -8,35 +8,37 @@ import (

// EconomicsHandlerMock -
type EconomicsHandlerMock struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

so many economic mocks

sasurobert
sasurobert previously approved these changes Oct 6, 2021
iulianpascalau
iulianpascalau previously approved these changes Oct 6, 2021
sasurobert
sasurobert previously approved these changes Oct 7, 2021
Copy link
Contributor

@LucianMincu LucianMincu left a comment

Choose a reason for hiding this comment

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

System tests passed.

@LucianMincu LucianMincu merged commit 1229c24 into development Oct 8, 2021
@LucianMincu LucianMincu deleted the reduce-max-gas-limit-per-mini-block branch October 8, 2021 09:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants