2016-04-14 19:18:24 +03:00
|
|
|
// Copyright 2015 The go-ethereum Authors
|
2015-10-19 17:08:17 +03:00
|
|
|
// This file is part of the go-ethereum library.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is free software: you can redistribute it and/or modify
|
|
|
|
// it under the terms of the GNU Lesser General Public License as published by
|
|
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
|
|
// (at your option) any later version.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is distributed in the hope that it will be useful,
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
// GNU Lesser General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU Lesser General Public License
|
|
|
|
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
package core
|
|
|
|
|
|
|
|
import (
|
2023-05-25 15:24:09 +03:00
|
|
|
"errors"
|
2015-10-19 17:08:17 +03:00
|
|
|
"fmt"
|
|
|
|
|
2024-06-25 14:48:08 +03:00
|
|
|
"github.com/ethereum/go-ethereum/common"
|
2017-04-05 01:16:29 +03:00
|
|
|
"github.com/ethereum/go-ethereum/consensus"
|
2015-10-19 17:08:17 +03:00
|
|
|
"github.com/ethereum/go-ethereum/core/state"
|
2024-06-25 14:48:08 +03:00
|
|
|
"github.com/ethereum/go-ethereum/core/stateless"
|
2015-10-19 17:08:17 +03:00
|
|
|
"github.com/ethereum/go-ethereum/core/types"
|
|
|
|
"github.com/ethereum/go-ethereum/params"
|
2020-08-21 15:10:40 +03:00
|
|
|
"github.com/ethereum/go-ethereum/trie"
|
2015-11-27 16:40:29 +02:00
|
|
|
)
|
|
|
|
|
2015-10-19 17:08:17 +03:00
|
|
|
// BlockValidator is responsible for validating block headers, uncles and
|
|
|
|
// processed state.
|
|
|
|
//
|
|
|
|
// BlockValidator implements Validator.
|
|
|
|
type BlockValidator struct {
|
2016-10-20 14:36:29 +03:00
|
|
|
config *params.ChainConfig // Chain configuration options
|
|
|
|
bc *BlockChain // Canonical block chain
|
2015-10-19 17:08:17 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// NewBlockValidator returns a new block validator which is safe for re-use
|
2024-06-25 14:48:08 +03:00
|
|
|
func NewBlockValidator(config *params.ChainConfig, blockchain *BlockChain) *BlockValidator {
|
2015-10-19 17:08:17 +03:00
|
|
|
validator := &BlockValidator{
|
2016-03-02 00:32:43 +02:00
|
|
|
config: config,
|
|
|
|
bc: blockchain,
|
2015-10-19 17:08:17 +03:00
|
|
|
}
|
|
|
|
return validator
|
|
|
|
}
|
|
|
|
|
2018-08-27 11:49:29 +03:00
|
|
|
// ValidateBody validates the given block's uncles and verifies the block
|
2017-04-05 01:16:29 +03:00
|
|
|
// header's transaction and uncle roots. The headers are assumed to be already
|
|
|
|
// validated at this point.
|
|
|
|
func (v *BlockValidator) ValidateBody(block *types.Block) error {
|
2023-02-06 22:52:51 +03:00
|
|
|
// Check whether the block is already imported.
|
2018-02-05 19:40:32 +03:00
|
|
|
if v.bc.HasBlockAndState(block.Hash(), block.NumberU64()) {
|
2017-06-27 16:57:06 +03:00
|
|
|
return ErrKnownBlock
|
2015-10-19 17:08:17 +03:00
|
|
|
}
|
2023-02-06 22:52:51 +03:00
|
|
|
|
|
|
|
// Header validity is known at this point. Here we verify that uncles, transactions
|
|
|
|
// and withdrawals given in the block body match the header.
|
2015-10-19 17:08:17 +03:00
|
|
|
header := block.Header()
|
2024-06-25 14:48:08 +03:00
|
|
|
if err := v.bc.engine.VerifyUncles(v.bc, block); err != nil {
|
2015-10-19 17:08:17 +03:00
|
|
|
return err
|
|
|
|
}
|
2017-04-05 01:16:29 +03:00
|
|
|
if hash := types.CalcUncleHash(block.Uncles()); hash != header.UncleHash {
|
2023-02-01 18:08:25 +03:00
|
|
|
return fmt.Errorf("uncle root hash mismatch (header value %x, calculated %x)", header.UncleHash, hash)
|
2015-10-19 17:08:17 +03:00
|
|
|
}
|
2020-09-29 18:38:13 +03:00
|
|
|
if hash := types.DeriveSha(block.Transactions(), trie.NewStackTrie(nil)); hash != header.TxHash {
|
2023-02-01 18:08:25 +03:00
|
|
|
return fmt.Errorf("transaction root hash mismatch (header value %x, calculated %x)", header.TxHash, hash)
|
2015-10-19 17:08:17 +03:00
|
|
|
}
|
core/types: support for optional blob sidecar in BlobTx (#27841)
This PR removes the newly added txpool.Transaction wrapper type, and instead adds a way
of keeping the blob sidecar within types.Transaction. It's better this way because most
code in go-ethereum does not care about blob transactions, and probably never will. This
will start mattering especially on the client side of RPC, where all APIs are based on
types.Transaction. Users need to be able to use the same signing flows they already
have.
However, since blobs are only allowed in some places but not others, we will now need to
add checks to avoid creating invalid blocks. I'm still trying to figure out the best place
to do some of these. The way I have it currently is as follows:
- In block validation (import), txs are verified not to have a blob sidecar.
- In miner, we strip off the sidecar when committing the transaction into the block.
- In TxPool validation, txs must have a sidecar to be added into the blobpool.
- Note there is a special case here: when transactions are re-added because of a chain
reorg, we cannot use the transactions gathered from the old chain blocks as-is,
because they will be missing their blobs. This was previously handled by storing the
blobs into the 'blobpool limbo'. The code has now changed to store the full
transaction in the limbo instead, but it might be confusing for code readers why we're
not simply adding the types.Transaction we already have.
Code changes summary:
- txpool.Transaction removed and all uses replaced by types.Transaction again
- blobpool now stores types.Transaction instead of defining its own blobTx format for storage
- the blobpool limbo now stores types.Transaction instead of storing only the blobs
- checks to validate the presence/absence of the blob sidecar added in certain critical places
2023-08-14 11:13:34 +03:00
|
|
|
|
2023-02-06 22:52:51 +03:00
|
|
|
// Withdrawals are present after the Shanghai fork.
|
2023-01-25 17:32:25 +03:00
|
|
|
if header.WithdrawalsHash != nil {
|
2023-02-06 22:52:51 +03:00
|
|
|
// Withdrawals list must be present in body after Shanghai.
|
|
|
|
if block.Withdrawals() == nil {
|
2023-05-25 15:24:09 +03:00
|
|
|
return errors.New("missing withdrawals in block body")
|
2023-02-06 22:52:51 +03:00
|
|
|
}
|
2023-01-25 17:32:25 +03:00
|
|
|
if hash := types.DeriveSha(block.Withdrawals(), trie.NewStackTrie(nil)); hash != *header.WithdrawalsHash {
|
2023-02-01 18:08:25 +03:00
|
|
|
return fmt.Errorf("withdrawals root hash mismatch (header value %x, calculated %x)", *header.WithdrawalsHash, hash)
|
2023-01-25 17:32:25 +03:00
|
|
|
}
|
2023-02-16 13:10:16 +03:00
|
|
|
} else if block.Withdrawals() != nil {
|
2023-05-31 10:21:13 +03:00
|
|
|
// Withdrawals are not allowed prior to Shanghai fork
|
2023-05-25 15:24:09 +03:00
|
|
|
return errors.New("withdrawals present in block body")
|
2023-01-25 17:32:25 +03:00
|
|
|
}
|
core/types: support for optional blob sidecar in BlobTx (#27841)
This PR removes the newly added txpool.Transaction wrapper type, and instead adds a way
of keeping the blob sidecar within types.Transaction. It's better this way because most
code in go-ethereum does not care about blob transactions, and probably never will. This
will start mattering especially on the client side of RPC, where all APIs are based on
types.Transaction. Users need to be able to use the same signing flows they already
have.
However, since blobs are only allowed in some places but not others, we will now need to
add checks to avoid creating invalid blocks. I'm still trying to figure out the best place
to do some of these. The way I have it currently is as follows:
- In block validation (import), txs are verified not to have a blob sidecar.
- In miner, we strip off the sidecar when committing the transaction into the block.
- In TxPool validation, txs must have a sidecar to be added into the blobpool.
- Note there is a special case here: when transactions are re-added because of a chain
reorg, we cannot use the transactions gathered from the old chain blocks as-is,
because they will be missing their blobs. This was previously handled by storing the
blobs into the 'blobpool limbo'. The code has now changed to store the full
transaction in the limbo instead, but it might be confusing for code readers why we're
not simply adding the types.Transaction we already have.
Code changes summary:
- txpool.Transaction removed and all uses replaced by types.Transaction again
- blobpool now stores types.Transaction instead of defining its own blobTx format for storage
- the blobpool limbo now stores types.Transaction instead of storing only the blobs
- checks to validate the presence/absence of the blob sidecar added in certain critical places
2023-08-14 11:13:34 +03:00
|
|
|
|
2023-05-31 10:21:13 +03:00
|
|
|
// Blob transactions may be present after the Cancun fork.
|
|
|
|
var blobs int
|
core/types: support for optional blob sidecar in BlobTx (#27841)
This PR removes the newly added txpool.Transaction wrapper type, and instead adds a way
of keeping the blob sidecar within types.Transaction. It's better this way because most
code in go-ethereum does not care about blob transactions, and probably never will. This
will start mattering especially on the client side of RPC, where all APIs are based on
types.Transaction. Users need to be able to use the same signing flows they already
have.
However, since blobs are only allowed in some places but not others, we will now need to
add checks to avoid creating invalid blocks. I'm still trying to figure out the best place
to do some of these. The way I have it currently is as follows:
- In block validation (import), txs are verified not to have a blob sidecar.
- In miner, we strip off the sidecar when committing the transaction into the block.
- In TxPool validation, txs must have a sidecar to be added into the blobpool.
- Note there is a special case here: when transactions are re-added because of a chain
reorg, we cannot use the transactions gathered from the old chain blocks as-is,
because they will be missing their blobs. This was previously handled by storing the
blobs into the 'blobpool limbo'. The code has now changed to store the full
transaction in the limbo instead, but it might be confusing for code readers why we're
not simply adding the types.Transaction we already have.
Code changes summary:
- txpool.Transaction removed and all uses replaced by types.Transaction again
- blobpool now stores types.Transaction instead of defining its own blobTx format for storage
- the blobpool limbo now stores types.Transaction instead of storing only the blobs
- checks to validate the presence/absence of the blob sidecar added in certain critical places
2023-08-14 11:13:34 +03:00
|
|
|
for i, tx := range block.Transactions() {
|
2023-07-27 16:53:28 +03:00
|
|
|
// Count the number of blobs to validate against the header's blobGasUsed
|
2023-05-31 10:21:13 +03:00
|
|
|
blobs += len(tx.BlobHashes())
|
core/types: support for optional blob sidecar in BlobTx (#27841)
This PR removes the newly added txpool.Transaction wrapper type, and instead adds a way
of keeping the blob sidecar within types.Transaction. It's better this way because most
code in go-ethereum does not care about blob transactions, and probably never will. This
will start mattering especially on the client side of RPC, where all APIs are based on
types.Transaction. Users need to be able to use the same signing flows they already
have.
However, since blobs are only allowed in some places but not others, we will now need to
add checks to avoid creating invalid blocks. I'm still trying to figure out the best place
to do some of these. The way I have it currently is as follows:
- In block validation (import), txs are verified not to have a blob sidecar.
- In miner, we strip off the sidecar when committing the transaction into the block.
- In TxPool validation, txs must have a sidecar to be added into the blobpool.
- Note there is a special case here: when transactions are re-added because of a chain
reorg, we cannot use the transactions gathered from the old chain blocks as-is,
because they will be missing their blobs. This was previously handled by storing the
blobs into the 'blobpool limbo'. The code has now changed to store the full
transaction in the limbo instead, but it might be confusing for code readers why we're
not simply adding the types.Transaction we already have.
Code changes summary:
- txpool.Transaction removed and all uses replaced by types.Transaction again
- blobpool now stores types.Transaction instead of defining its own blobTx format for storage
- the blobpool limbo now stores types.Transaction instead of storing only the blobs
- checks to validate the presence/absence of the blob sidecar added in certain critical places
2023-08-14 11:13:34 +03:00
|
|
|
|
|
|
|
// If the tx is a blob tx, it must NOT have a sidecar attached to be valid in a block.
|
|
|
|
if tx.BlobTxSidecar() != nil {
|
|
|
|
return fmt.Errorf("unexpected blob sidecar in transaction at index %d", i)
|
|
|
|
}
|
|
|
|
|
2023-07-16 00:27:36 +03:00
|
|
|
// The individual checks for blob validity (version-check + not empty)
|
core/types: support for optional blob sidecar in BlobTx (#27841)
This PR removes the newly added txpool.Transaction wrapper type, and instead adds a way
of keeping the blob sidecar within types.Transaction. It's better this way because most
code in go-ethereum does not care about blob transactions, and probably never will. This
will start mattering especially on the client side of RPC, where all APIs are based on
types.Transaction. Users need to be able to use the same signing flows they already
have.
However, since blobs are only allowed in some places but not others, we will now need to
add checks to avoid creating invalid blocks. I'm still trying to figure out the best place
to do some of these. The way I have it currently is as follows:
- In block validation (import), txs are verified not to have a blob sidecar.
- In miner, we strip off the sidecar when committing the transaction into the block.
- In TxPool validation, txs must have a sidecar to be added into the blobpool.
- Note there is a special case here: when transactions are re-added because of a chain
reorg, we cannot use the transactions gathered from the old chain blocks as-is,
because they will be missing their blobs. This was previously handled by storing the
blobs into the 'blobpool limbo'. The code has now changed to store the full
transaction in the limbo instead, but it might be confusing for code readers why we're
not simply adding the types.Transaction we already have.
Code changes summary:
- txpool.Transaction removed and all uses replaced by types.Transaction again
- blobpool now stores types.Transaction instead of defining its own blobTx format for storage
- the blobpool limbo now stores types.Transaction instead of storing only the blobs
- checks to validate the presence/absence of the blob sidecar added in certain critical places
2023-08-14 11:13:34 +03:00
|
|
|
// happens in StateTransition.
|
2023-05-31 10:21:13 +03:00
|
|
|
}
|
core/types: support for optional blob sidecar in BlobTx (#27841)
This PR removes the newly added txpool.Transaction wrapper type, and instead adds a way
of keeping the blob sidecar within types.Transaction. It's better this way because most
code in go-ethereum does not care about blob transactions, and probably never will. This
will start mattering especially on the client side of RPC, where all APIs are based on
types.Transaction. Users need to be able to use the same signing flows they already
have.
However, since blobs are only allowed in some places but not others, we will now need to
add checks to avoid creating invalid blocks. I'm still trying to figure out the best place
to do some of these. The way I have it currently is as follows:
- In block validation (import), txs are verified not to have a blob sidecar.
- In miner, we strip off the sidecar when committing the transaction into the block.
- In TxPool validation, txs must have a sidecar to be added into the blobpool.
- Note there is a special case here: when transactions are re-added because of a chain
reorg, we cannot use the transactions gathered from the old chain blocks as-is,
because they will be missing their blobs. This was previously handled by storing the
blobs into the 'blobpool limbo'. The code has now changed to store the full
transaction in the limbo instead, but it might be confusing for code readers why we're
not simply adding the types.Transaction we already have.
Code changes summary:
- txpool.Transaction removed and all uses replaced by types.Transaction again
- blobpool now stores types.Transaction instead of defining its own blobTx format for storage
- the blobpool limbo now stores types.Transaction instead of storing only the blobs
- checks to validate the presence/absence of the blob sidecar added in certain critical places
2023-08-14 11:13:34 +03:00
|
|
|
|
|
|
|
// Check blob gas usage.
|
2023-07-27 16:53:28 +03:00
|
|
|
if header.BlobGasUsed != nil {
|
|
|
|
if want := *header.BlobGasUsed / params.BlobTxBlobGasPerBlob; uint64(blobs) != want { // div because the header is surely good vs the body might be bloated
|
2023-08-01 10:07:25 +03:00
|
|
|
return fmt.Errorf("blob gas used mismatch (header %v, calculated %v)", *header.BlobGasUsed, blobs*params.BlobTxBlobGasPerBlob)
|
2023-05-31 10:21:13 +03:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if blobs > 0 {
|
|
|
|
return errors.New("data blobs present in block body")
|
|
|
|
}
|
|
|
|
}
|
core/types: support for optional blob sidecar in BlobTx (#27841)
This PR removes the newly added txpool.Transaction wrapper type, and instead adds a way
of keeping the blob sidecar within types.Transaction. It's better this way because most
code in go-ethereum does not care about blob transactions, and probably never will. This
will start mattering especially on the client side of RPC, where all APIs are based on
types.Transaction. Users need to be able to use the same signing flows they already
have.
However, since blobs are only allowed in some places but not others, we will now need to
add checks to avoid creating invalid blocks. I'm still trying to figure out the best place
to do some of these. The way I have it currently is as follows:
- In block validation (import), txs are verified not to have a blob sidecar.
- In miner, we strip off the sidecar when committing the transaction into the block.
- In TxPool validation, txs must have a sidecar to be added into the blobpool.
- Note there is a special case here: when transactions are re-added because of a chain
reorg, we cannot use the transactions gathered from the old chain blocks as-is,
because they will be missing their blobs. This was previously handled by storing the
blobs into the 'blobpool limbo'. The code has now changed to store the full
transaction in the limbo instead, but it might be confusing for code readers why we're
not simply adding the types.Transaction we already have.
Code changes summary:
- txpool.Transaction removed and all uses replaced by types.Transaction again
- blobpool now stores types.Transaction instead of defining its own blobTx format for storage
- the blobpool limbo now stores types.Transaction instead of storing only the blobs
- checks to validate the presence/absence of the blob sidecar added in certain critical places
2023-08-14 11:13:34 +03:00
|
|
|
|
|
|
|
// Ancestor block must be known.
|
2018-11-07 15:47:11 +03:00
|
|
|
if !v.bc.HasBlockAndState(block.ParentHash(), block.NumberU64()-1) {
|
|
|
|
if !v.bc.HasBlock(block.ParentHash(), block.NumberU64()-1) {
|
|
|
|
return consensus.ErrUnknownAncestor
|
|
|
|
}
|
|
|
|
return consensus.ErrPrunedAncestor
|
|
|
|
}
|
2015-10-19 17:08:17 +03:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2023-03-16 22:34:25 +03:00
|
|
|
// ValidateState validates the various changes that happen after a state transition,
|
|
|
|
// such as amount of used gas, the receipt roots and the state root itself.
|
2024-06-25 14:48:08 +03:00
|
|
|
func (v *BlockValidator) ValidateState(block *types.Block, statedb *state.StateDB, receipts types.Receipts, usedGas uint64, stateless bool) error {
|
2015-10-19 17:08:17 +03:00
|
|
|
header := block.Header()
|
2017-11-13 14:47:27 +03:00
|
|
|
if block.GasUsed() != usedGas {
|
|
|
|
return fmt.Errorf("invalid gas used (remote: %d local: %d)", block.GasUsed(), usedGas)
|
2015-10-19 17:08:17 +03:00
|
|
|
}
|
|
|
|
// Validate the received block's bloom with the one derived from the generated receipts.
|
|
|
|
// For valid blocks this should always validate to true.
|
|
|
|
rbloom := types.CreateBloom(receipts)
|
|
|
|
if rbloom != header.Bloom {
|
2016-11-23 15:32:25 +03:00
|
|
|
return fmt.Errorf("invalid bloom (remote: %x local: %x)", header.Bloom, rbloom)
|
2015-10-19 17:08:17 +03:00
|
|
|
}
|
2024-06-25 14:48:08 +03:00
|
|
|
// In stateless mode, return early because the receipt and state root are not
|
|
|
|
// provided through the witness, rather the cross validator needs to return it.
|
|
|
|
if stateless {
|
|
|
|
return nil
|
|
|
|
}
|
2024-04-08 14:02:56 +03:00
|
|
|
// The receipt Trie's root (R = (Tr [[H1, R1], ... [Hn, Rn]]))
|
2020-09-29 18:38:13 +03:00
|
|
|
receiptSha := types.DeriveSha(receipts, trie.NewStackTrie(nil))
|
2015-10-19 17:08:17 +03:00
|
|
|
if receiptSha != header.ReceiptHash {
|
2016-11-23 15:32:25 +03:00
|
|
|
return fmt.Errorf("invalid receipt root hash (remote: %x local: %x)", header.ReceiptHash, receiptSha)
|
2015-10-19 17:08:17 +03:00
|
|
|
}
|
|
|
|
// Validate the state root against the received state root and throw
|
|
|
|
// an error if they don't match.
|
2016-10-20 14:36:29 +03:00
|
|
|
if root := statedb.IntermediateRoot(v.config.IsEIP158(header.Number)); header.Root != root {
|
2023-03-16 10:12:34 +03:00
|
|
|
return fmt.Errorf("invalid merkle root (remote: %x local: %x) dberr: %w", header.Root, root, statedb.Error())
|
2015-10-19 17:08:17 +03:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2024-06-25 14:48:08 +03:00
|
|
|
// ValidateWitness cross validates a block execution with stateless remote clients.
|
|
|
|
//
|
|
|
|
// Normally we'd distribute the block witness to remote cross validators, wait
|
|
|
|
// for them to respond and then merge the results. For now, however, it's only
|
|
|
|
// Geth, so do an internal stateless run.
|
|
|
|
func (v *BlockValidator) ValidateWitness(witness *stateless.Witness, receiptRoot common.Hash, stateRoot common.Hash) error {
|
|
|
|
// Run the cross client stateless execution
|
|
|
|
// TODO(karalabe): Self-stateless for now, swap with other clients
|
|
|
|
crossReceiptRoot, crossStateRoot, err := ExecuteStateless(v.config, witness)
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("stateless execution failed: %v", err)
|
|
|
|
}
|
|
|
|
// Stateless cross execution suceeeded, validate the withheld computed fields
|
|
|
|
if crossReceiptRoot != receiptRoot {
|
|
|
|
return fmt.Errorf("cross validator receipt root mismatch (cross: %x local: %x)", crossReceiptRoot, receiptRoot)
|
|
|
|
}
|
|
|
|
if crossStateRoot != stateRoot {
|
|
|
|
return fmt.Errorf("cross validator state root mismatch (cross: %x local: %x)", crossStateRoot, stateRoot)
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-08-29 12:21:12 +03:00
|
|
|
// CalcGasLimit computes the gas limit of the next block after parent. It aims
|
2021-08-10 11:28:33 +03:00
|
|
|
// to keep the baseline gas close to the provided target, and increase it towards
|
|
|
|
// the target if the baseline gas is lower.
|
|
|
|
func CalcGasLimit(parentGasLimit, desiredLimit uint64) uint64 {
|
2021-05-21 10:59:26 +03:00
|
|
|
delta := parentGasLimit/params.GasLimitBoundDivisor - 1
|
|
|
|
limit := parentGasLimit
|
|
|
|
if desiredLimit < params.MinGasLimit {
|
|
|
|
desiredLimit = params.MinGasLimit
|
|
|
|
}
|
|
|
|
// If we're outside our allowed gas range, we try to hone towards them
|
|
|
|
if limit < desiredLimit {
|
|
|
|
limit = parentGasLimit + delta
|
|
|
|
if limit > desiredLimit {
|
|
|
|
limit = desiredLimit
|
|
|
|
}
|
|
|
|
return limit
|
|
|
|
}
|
|
|
|
if limit > desiredLimit {
|
|
|
|
limit = parentGasLimit - delta
|
|
|
|
if limit < desiredLimit {
|
|
|
|
limit = desiredLimit
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return limit
|
|
|
|
}
|