-
Notifications
You must be signed in to change notification settings - Fork 198
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
Conversation
…(10 min to 1 hour)
…1 hour to 10 min)
# Conflicts: # config/tomlConfig_test.go
…-gas-limit-per-mini-block # Conflicts: # process/block/preprocess/transactions.go # process/mock/gasHandlerMock.go
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
…ross shard mini block from me is reached
# 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
# Conflicts: # factory/blockProcessorCreator.go # genesis/process/metaGenesisBlockCreator.go # genesis/process/shardGenesisBlockCreator.go # integrationTests/testProcessorNode.go # process/smartContract/process.go
…ed-in-cross-dest-me-mbs
…mit-per-mini-block
There was a problem hiding this 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"}, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
conversionBase := 10 | ||
bitConversionSize := 64 | ||
for _, gasLimitSetting := range economics.FeeSettings.GasLimitSettings { | ||
minGasLimit, err := strconv.ParseUint(gasLimitSetting.MinGasLimit, conversionBase, bitConversionSize) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
@@ -976,6 +1026,7 @@ func (tc *transactionCoordinator) VerifyCreatedBlockTransactions(hdr data.Header | |||
}(interimProc) | |||
} | |||
|
|||
tc.mutInterimProcessors.RUnlock() | |||
wg.Wait() |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
@@ -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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
@@ -976,6 +1026,7 @@ func (tc *transactionCoordinator) VerifyCreatedBlockTransactions(hdr data.Header | |||
}(interimProc) | |||
} | |||
|
|||
tc.mutInterimProcessors.RUnlock() | |||
wg.Wait() |
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so many economic mocks
# Conflicts: # process/smartContract/process.go
6580158
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
System tests passed.
Testing scenario:
txgen branch: temp-increase-gas-erc20-esdt
txgen starting command: ./start.sh start 100 base