Fixes lint issue
>>> /home/appveyor/.gvm/gos/go1.24.0/bin/go generate ./...
ci.go:404: File changed: .git/index
ci.go:407: One or more generated files were updated by running 'go generate ./...'
exit status 1
We forgot to add the deposit contract address for holesky, causing
deposits to not be flagged correctly
---------
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
In this PR, several improvements have been made:
Authorization-related validations have been moved to legacyPool.
Previously, these checks were part of the standard validation procedure,
which applies common validations across different pools. Since these
checks are specific to SetCode transactions, relocating them to
legacyPool
is a more reasonable choice.
Additionally, authorization conflict checks are now performed regardless
of whether the transaction is a replacement or not.
---------
Co-authored-by: lightclient <lightclient@protonmail.com>
Updates cloudflare-go from v0.79.0 to v0.114.0 which also gets rid of a
dependency to `github.com/hashicorp/go-retryablehttp` which had a
security flaw.
Diff:
https://github.com/cloudflare/cloudflare-go/compare/v0.79.0...v0.114.0
I did a quick sanity check on the diff on all methods that we use and
went through the release notes, there was nothing related to how we use
it afaict
I ran into this while trying to debug a discv5 thing. I tried to disable
DNS discovery using `--discovery.dns=false`, which doesn't work.
Annoyingly, geth started anyway and discarded the error silently. I
eventually found my mistake, but it took way longer than it should have.
Also including a small change to the error message for invalid DNS URLs
here. The user actually needs to see the URL to make sense of the error.
Fixed broken or outdated links and improved documentation formatting to
ensure consistency and correct references.
---------
Co-authored-by: Sina M <1591639+s1na@users.noreply.github.com>
Shout-out to @Gabriel-Trintinalia for discovering this issue. The gist
of it as follows:
When processing a block, we should provide the parent block as well as
the last 256 block hashes. Some of these parents data (specifically the
hash) was incorrect because even though during the processing of the
parent block we have updated the header, that header was not updating
the TransactionsRoot and ReceiptsRoot fields (types.NewBlock makes a new
copy of the header and changes it only on that instance).
---------
Co-authored-by: lightclient <lightclient@protonmail.com>
The test occasionally fails when network connectivity is bad or if it
hits the wrong server. We usually don't add tests with external network
dependency so I'm removing them.
Fixes#31220
eth_simulate was not processing prague system calls for history contract and EL
requests resulting in inaccurate stateRoot and requestsRoot fields in the block.
I maintain an improved version of the go-ethereum assembler at
https://github.com/fjl/geas. We don't really use core/asm in our tests,
and it has some bugs that prevent it from being useful, so I'm removing
the package.
This PR does a few things including:
- Remove `ContractRef` interface
- Remove `vm.AccountRef` which implements `ContractRef` interface
- Maintain the `jumpDests` struct in EVM for sharing between call frames
- Simplify the delegateCall context initialization
Adds a comment on how to use rpc.*BlockNumber and the explanation of the block number tags
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
This PR removes the assumption of the stacktrie and trie to have the
same ordering. This was hit by the fuzzers on oss-fuzz
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
This fixes a regression introduced in #31153 where we didn't consider
mainnet to be in PoS, causing #31190.
The problem is, `params.MainnetChainConfig` does not have a defined
`MergeNetsplitBlock`, so it isn't considered to be in PoS in
`CalcDifficulty`.
Currently, when calculating block's bloom, we loop through all the
receipt logs to calculate the hash value. However, normally, after going
through applyTransaction, the receipt's bloom is already calculated
based on the receipt log, so the block's bloom can be calculated by just
ORing these receipt's blooms.
```
goos: darwin
goarch: arm64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: Apple M1 Pro
BenchmarkCreateBloom
BenchmarkCreateBloom/small
BenchmarkCreateBloom/small-10 810922 1481 ns/op 104 B/op 5 allocs/op
BenchmarkCreateBloom/large
BenchmarkCreateBloom/large-10 8173 143764 ns/op 9614 B/op 401 allocs/op
BenchmarkCreateBloom/small-mergebloom
BenchmarkCreateBloom/small-mergebloom-10 5178918 232.0 ns/op 0 B/op 0 allocs/op
BenchmarkCreateBloom/large-mergebloom
BenchmarkCreateBloom/large-mergebloom-10 54110 22207 ns/op 0 B/op 0 allocs/op
```
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
Co-authored-by: Zsolt Felfoldi <zsfelfoldi@gmail.com>
This PR addresses a flaw in the freezer table upgrade path.
In v1.15.0, freezer table v2 was introduced, including an additional
field (`flushOffset`) maintained in the metadata file. To ensure
backward compatibility, an upgrade path was implemented for legacy
freezer tables by setting `flushOffset` to the size of the index file.
However, if the freezer table is opened in read-only mode, this file
write operation is rejected, causing Geth to shut down entirely.
Given that invalid items in the freezer index file can be detected and
truncated, all items in freezer v0 index files are guaranteed to be
complete. Therefore, when operating in read-only mode, it is safe to
use the freezer data without performing an upgrade.
This is to prevent a crash on startup with a custom genesis configuration.
With this change in place, upgrading a chain created by geth v1.14.x and
below will now print an error instead of crashing:
Fatal: Failed to register the Ethereum service: invalid chain configuration: missing entry for fork "cancun" in blobSchedule
Arguably this is not great, and it should just auto-upgrade the config.
We'll address this in a follow-up PR for geth v1.15.2
This fixes an error where executing `evm run --dump ...` omits preimages
from the dump (because the statedb used for execution is a copy of
another instance).
The new SetCode transaction type introduces some additional complexity
when handling the transaction pool.
This complexity stems from two new account behaviors:
1. The balance and nonce of an account can change during regular
transaction execution *when they have a deployed delegation*.
2. The nonce and code of an account can change without any EVM execution
at all. This is the "set code" mechanism introduced by EIP-7702.
The first issue has already been considered extensively during the design
of ERC-4337, and we're relatively confident in the solution of simply
limiting the number of in-flight pending transactions an account can have
to one. This puts a reasonable bound on transaction cancellation. Normally
to cancel, you would need to spend 21,000 gas. Now it's possible to cancel
for around the cost of warming the account and sending value
(`2,600+9,000=11,600`). So 50% cheaper.
The second issue is more novel and needs further consideration.
Since authorizations are not bound to a specific transaction, we
cannot drop transactions with conflicting authorizations. Otherwise,
it might be possible to cherry-pick authorizations from txs and front
run them with different txs at much lower fee amounts, effectively DoSing
the authority. Fortunately, conflicting authorizations do not affect the
underlying validity of the transaction so we can just accept both.
---------
Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de>
Co-authored-by: Felix Lange <fjl@twurst.com>
Ragnar
Felföldi Zsolt
James
rjl493456442
Felix Lange
Shude Li
jwasinger
Marius van der Wijden
levisyin
Maximilian Hubert
Sina M
rrhlrmrr
Martin HS
Delweng
nethoxa
Matthieu Vachon
EdisonSR
piersy
minh-bq
lightclient