Miner configuration is unified under [Eth.Miner] (GasCeil/GasPrice/Etherbase/ExtraData), replacing legacy top-level [Eth] miner keys.
Operational impact: existing config files using [Eth].GasPrice/[Eth].Etherbase/[Eth].ExtraData must be migrated before upgrade.
Behavior update: gasprice=0 remains valid; only negative gas prices are sanitized at startup.
Default change: XDCGenesisGasLimit is reduced to 42,000,000 and now feeds miner default GasCeil (including default --miner-gaslimit), so nodes relying on defaults should review capacity expectations.
This commit removes two redundant SetGasPrice() calls in the startNode function that were causing multiple issues:
1. Overriding txpool's configured price limit with the miner's gas price setting, mixing two independent configurations:
- cfg.Eth.GasPrice (from --miner-gasprice --gasprice flag)
- cfg.TxPool.PriceLimit (from --txpool-pricelimit flag)
2. Reverting runtime gasPrice changes made via RPC. When users call miner_setGasPrice RPC method to adjust the gasPrice dynamically, the changes would be unexpectedly reverted at the next checkpoint when startNode re-applies cfg.Eth.GasPrice.
The txpool already initializes its gasPrice from config.PriceLimit during construction (core/txpool/txpool.go:333):
```go
func NewTxPool(config Config, chainconfig *params.ChainConfig, chain blockChain) *TxPool {
pool := &TxPool{
gasPrice: new(big.Int).SetUint64(config.PriceLimit),
}
```
When mining is started via RPC (miner_start), the MinerAPI.Start() method handles gasPrice propagation correctly.
This change ensures:
- The txpool respects its own configuration
- Runtime gasPrice adjustments via RPC persist across checkpoints
- No unexpected overriding of user-configured values
Here we add a Go API for running tracing plugins within the main block import process.
As an advanced user of geth, you can now create a Go file in eth/tracers/live/, and within
that file register your custom tracer implementation. Then recompile geth and select your tracer
on the command line. Hooks defined in the tracer will run whenever a block is processed.
The hook system is defined in package core/tracing. It uses a struct with callbacks, instead of
requiring an interface, for several reasons:
- We plan to keep this API stable long-term. The core/tracing hook API does not depend on
on deep geth internals.
- There are a lot of hooks, and tracers will only need some of them. Using a struct allows you
to implement only the hooks you want to actually use.
All existing tracers in eth/tracers/native have been rewritten to use the new hook system.
This change breaks compatibility with the vm.EVMLogger interface that we used to have.
If you are a user of vm.EVMLogger, please migrate to core/tracing, and sorry for breaking
your stuff. But we just couldn't have both the old and new tracing APIs coexist in the EVM.
---------
Co-authored-by: Sina M <1591639+s1na@users.noreply.github.com>
Co-authored-by: Matthieu Vachon <matthieu.o.vachon@gmail.com>
Co-authored-by: Delweng <delweng@gmail.com>
Co-authored-by: Martin HS <martin@swende.se>
This PR modifies how the metrics library handles `Enabled`: previously,
the package `init` decided whether to serve real metrics or just
dummy-types.
This has several drawbacks:
- During pkg init, we need to determine whether metrics are enabled or
not. So we first hacked in a check if certain geth-specific
commandline-flags were enabled. Then we added a similar check for
geth-env-vars. Then we almost added a very elaborate check for
toml-config-file, plus toml parsing.
- Using "real" types and dummy types interchangeably means that
everything is hidden behind interfaces. This has a performance penalty,
and also it just adds a lot of code.
This PR removes the interface stuff, uses concrete types, and allows for
the setting of Enabled to happen later. It is still assumed that
`metrics.Enable()` is invoked early on.
The somewhat 'heavy' operations, such as ticking meters and exp-decay,
now checks the enable-flag to prevent resource leak.
The change may be large, but it's mostly pretty trivial, and from the
last time I gutted the metrics, I ensured that we have fairly good test
coverage.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
