With EOF removed from the Osaka fork, and no longer being tested, the
implementation will now just be bitrotting. I'm opting to remove it so
it doesn't get in the way of other changes.
This pull request introduces a new test suite in workload framework, for
transaction tracing.
**test generation**
`go run . tracegen --trace-tests trace-test.json http://host:8545`
and you can choose to store the trace result in a specific folder
`go run . tracegen --trace-tests trace-test.json --trace-output
./trace-result http://host:8545`
**test run**
`./workload test -run Trace/Transaction --trace-invalid ./trace-invalid
http://host:8545`
The mismatched trace result will be saved in the specific folder for
further investigation.
This changes the era1 downloader to place the files into the correct
location where geth will actually use them. Also adds integration with
the new --datadir.era flag.
This implements a backing store for chain history based on era1 files.
The new store is integrated with the freezer. Queries for blocks and receipts
below the current freezer tail are handled by the era store.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
Co-authored-by: Felix Lange <fjl@twurst.com>
Co-authored-by: lightclient <lightclient@protonmail.com>
This PR modifies the disclaimer/banner that is printed when starting up
Geth in dev mode:
* if the client is spun up in ephemeral dev mode with a keystore
override, the address of the first (prefunded) account is printed.
* if the client is spun up in ephemeral mode without a keystore
override, the genesis allocation contains a single static prefunded EOA
account. It's address and private key are logged.
* the banner is printed at the end of client initialization to make it
more prominent. Previously, it was logged towards the beginning of
client initialization and subsequent logging from startup filled the
terminal, pushing it out of view of the user.
Other change is that we now use a static prefunded dev account instead
of generating a random one when instantiating a new dev mode chain.
This is an example of what the banner looks like:
```
WARN [05-28|23:05:16.475] You are running Geth in --dev mode. Please note the following:
WARN [05-28|23:05:16.475]
WARN [05-28|23:05:16.475] 1. This mode is only intended for fast, iterative development without assumptions on
WARN [05-28|23:05:16.475] security or persistence.
WARN [05-28|23:05:16.475] 2. The database is created in memory unless specified otherwise. Therefore, shutting down
WARN [05-28|23:05:16.475] your computer or losing power will wipe your entire block data and chain state for
WARN [05-28|23:05:16.475] your dev environment.
WARN [05-28|23:05:16.475] 3. A random, pre-allocated developer account will be available and unlocked as
WARN [05-28|23:05:16.475] eth.coinbase, which can be used for testing. The random dev account is temporary,
WARN [05-28|23:05:16.475] stored on a ramdisk, and will be lost if your machine is restarted.
WARN [05-28|23:05:16.475] 4. Mining is enabled by default. However, the client will only seal blocks if transactions
WARN [05-28|23:05:16.475] are pending in the mempool. The miner's minimum accepted gas price is 1.
WARN [05-28|23:05:16.475] 5. Networking is disabled; there is no listen-address, the maximum number of peers is set
WARN [05-28|23:05:16.475] to 0, and discovery is disabled.
WARN [05-28|23:05:16.475]
WARN [05-28|23:05:16.475]
WARN [05-28|23:05:16.475] Running in ephemeral mode. The following account has been prefunded in the genesis:
WARN [05-28|23:05:16.475]
WARN [05-28|23:05:16.475] Account
WARN [05-28|23:05:16.475] ------------------
WARN [05-28|23:05:16.475] 0x71562b71999873db5b286df957af199ec94617f7 (10^49 ETH)
WARN [05-28|23:05:16.475]
WARN [05-28|23:05:16.475] Private Key
WARN [05-28|23:05:16.475] ------------------
WARN [05-28|23:05:16.475] 0xb71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291
WARN [05-28|23:05:16.475]
```
closes#31796
---------
Co-authored-by: jwasinger <j-wasinger@hotmail.com>
I added a test for BlockRangeUpdate in #29158 but forgot to enable it.
Here I'm adding two more tests for it. Also applied a small refactoring
to combine calls to `dial()` and `peer()` into a single function, since
these two calls are duplicated in each test.
This PR implements eth/69. This protocol version drops the bloom filter
from receipts messages, reducing the amount of data needed for a sync
by ~530GB (2.3B txs * 256 byte) uncompressed. Compressed this will
be reduced to ~100GB
The new version also changes the Status message and introduces the
BlockRangeUpdate message to relay information about the available history
range.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
This adds a geth subcommand for downloading era1 files and placing them into
the correct location. The tool can be used even while geth is already running
on the datadir. Downloads are checked against a hard-coded list of checksums
for mainnet and sepolia.
```
./geth download-era --server $SERVER --block 333333
./geth download-era --server $SERVER --block 333333-444444
./geth download-era --server $SERVER --epoch 0-10
./geth download-era --server $SERVER --all
```
The implementation reuses the file downloader we already had for
fetching build tools. I've done some refactoring on it to make sure it
can support the new use case, and there are some changes to the build
here as well.
Add tests for GetBlockHeaders that verify client does not disconnect when unlikely block numbers are requested, e.g. max uint64.
---------
Co-authored-by: lightclient <lightclient@protonmail.com>
For PeerDAS, we need to compute cell proofs. Both ckzg and gokzg support
computing these cell proofs.
This PR does the following:
- Update the go-kzg library from "github.com/crate-crypto/go-kzg-4844"
to "github.com/crate-crypto/go-eth-kzg" which will be the new upstream
for go-kzg moving forward
- Update ckzg from v1.0.0 to v2.0.1 and switch to /v2
- Updates the trusted setup to contain the g1 points both in lagrange
and monomial form
- Expose `ComputeCells` to compute the cell proofs
I added the history mode configuration in eth/ethconfig initially, since
it seemed like the logical place. But it turns out we need access to the
intended pruning setting at a deeper level, and it actually needs to be
integrated with the blockchain startup procedure.
With this change applied, if a node previously had its history pruned,
and is subsequently restarted **without** the `--history.chain
postmerge` flag, the `BlockChain` initialization code will now verify
the freezer tail against the known pruning point of the predefined
network and will restore pruning status. Note that this logic is quite
restrictive, we allow non-zero tail only for known networks, and only
for the specific pruning point that is defined.
This PR adds a new `--beacon.checkpoint.file` config flag to geth and
blsync which specifies a checkpoint import/export file. If a file with
an existing checkpoint is specified, it is used for initialization
instead of the hardcoded one (except when `--beacon.checkpoint` is also
specified simultaneously). Whenever the client encounters a new valid
finality update with a suitable finalized beacon block root at an epoch
boundary, it saves the block root in hex format to the checkpoint file.
This adds the test description text to the output, instead of keeping it
as a Go comment. Logs are visible in the hive UI where these tests run,
while Go comments are not.
This pull request introduces new sync logic for pruning mode. The downloader will now skip
insertion of block bodies and receipts before the configured history cutoff point.
Originally, in snap sync, the header chain and other components (bodies and receipts) were
inserted separately. However, in Proof-of-Stake, this separation is unnecessary since the
sync target is already verified by the CL.
To simplify the process, this pull request modifies `InsertReceiptChain` to insert headers
along with block bodies and receipts together. Besides, `InsertReceiptChain` doesn't have
the notion of reorg, as the common ancestor is always be found before the sync and extra
side chain is truncated at the beginning if they fall in the ancient store. The stale
canonical chain flags will always be rewritten by the new chain. Explicit reorg logic is
no longer required in `InsertReceiptChain`.
This adds a new subcommand 'geth prune-history' that removes the pre-merge history
on supported networks. Geth is not fully ready to work in this mode, please do not run
this command on your production node.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
This PR fixes the broken request error handling of the workload filter
tests. Until now `validateHistoryPruneErr` was invoked with `fq.Err` as
an input which was always nil and a timeout or http error was reported
as a result content mismatch.
Also, in case of `errPrunedHistory` it is wrong to return here without
setting an error because then it will look like a valid empty result and
the check will later fail. So instead `errPrunedHistory` is always
returned now (without printing an error message) and the callers of
`run` should handle this special case (typically ignore silently).
This removes the signer type-train in favor of defining a single object
that can handle all tx types. Supported types are enabled via a map.
Notably, the new signer also supports disabling legacy transactions.
When I'm running `geth import --metrics`, the metrics is different to
normal `geth --metrics`, so the grafana dashboard needs to be updated,
eg: `eth_db_chaindata_disk_read` vs `disk_read`.
So I think we should always set the name to `eth/db/chaindata` for more
convenient.
---------
Signed-off-by: jsvisa <delweng@gmail.com>
This PR implements a new version of the abigen utility (v2) which exists
along with the pre-existing v1 version.
Abigen is a utility command provided by go-ethereum that, given a
solidity contract ABI definition, will generate Go code to transact/call
the contract methods, converting the method parameters/results and
structures defined in the contract into corresponding Go types. This is
useful for preventing the need to write custom boilerplate code for
contract interactions.
Methods in the generated bindings perform encoding between Go types and
Solidity ABI-encoded packed bytecode, as well as some action (e.g.
`eth_call` or creating and submitting a transaction). This limits the
flexibility of how the generated bindings can be used, and prevents
easily adding new functionality, as it will make the generated bindings
larger for each feature added.
Abigen v2 was conceived of by the observation that the only
functionality that generated Go bindings ought to perform is conversion
between Go types and ABI-encoded packed data. Go-ethereum already
provides various APIs which in conjunction with conversion methods
generated in v2 bindings can cover all functionality currently provided
by v1, and facilitate all other previously-desired use-cases.
## Generating Bindings
To generate contract bindings using abigen v2, invoke the `abigen`
command with the `--v2` flag. The functionality of all other flags is
preserved between the v2 and v1 versions.
## What is Generated in the Bindings
The execution of `abigen --v2` generates Go code containing methods
which convert between Go types and corresponding ABI-encoded data
expected by the contract. For each input-accepting contract method and
the constructor, a "packing" method is generated in the binding which
converts from Go types to the corresponding packed solidity expected by
the contract. If a method returns output, an "unpacking" method is
generated to convert this output from ABI-encoded data to the
corresponding Go types.
For contracts which emit events, an unpacking method is defined for each
event to unpack the corresponding raw log to the Go type that it
represents.
Likewise, where custom errors are defined by contracts, an unpack method
is generated to unpack raw error data into a Go type.
## Using the Generated Bindings
For a smooth user-experience, abigen v2 comes with a number of utility
functions to be used in conjunction with the generated bindings for
performing common contract interaction use-cases. These include:
* filtering for historical logs of a given topic
* watching the chain for emission of logs with a given topic
* contract deployment methods
* Call/Transact methods
https://geth.ethereum.org will be updated to include a new tutorial page
for abigen v2 with full code examples. The page currently exists in a
PR: https://github.com/ethereum/go-ethereum/pull/31390 .
There are also extensive examples of interactions with contract bindings
in [test
cases](cc855c7ede/accounts/abi/bind/v2/lib_test.go)
provided with this PR.
---------
Co-authored-by: Sina Mahmoodi <itz.s1na@gmail.com>
Co-authored-by: Felix Lange <fjl@twurst.com>
this adds 2 features to improve `geth --dev` experience.
1. we don't need to use `dev_SetFeeRecipient` to set initial coinbase
address. it was a pain.
2. we don't need to unlock keystore if we don't use it. we had it
because of clique.
Fixes `evm statetest` for state test fixtures with multiple fork entries
in their `post` field (e.g.,
[chainId.json](81862e4848/GeneralStateTests/stChainId/chainId.json (L39))).
When these re-activated flags aren't exposed, `statetest` only executes
the fixture for a single fork entry instead of all of the forks as
expected.
This only affects ethereum/tests state test fixtures, not
ethereum/execution-spec-tests (EEST) state tests. EEST writes a separate
fixture/test case (i.e. a separate top-level dict entry in the .json)
for each fork configuration as apposed to combining multiple forks in
one fixture test case: New EEST state tests targeting Prague behavior
are not affected.
Fixes#31093
Here we add some API functions on the UDPv5 object for the purpose of implementing
the Portal Network JSON-RPC API in the shisui client.
---------
Signed-off-by: Chen Kai <281165273grape@gmail.com>
Here I am adding a config option and geth flag (`--history.chain`) for
configuring history pruning. There are two options available:
- `--history.chain all` is the default and will keep all history like
before.
- `--history.chain postmerge` will configure the history cutoff point to
the merge block.
The option doesn't actually do anything right now, but we need it as a
precursor for other history pruning changes.
When I press Ctrl-C during the import of multiple files, the import
process will still attempt to import the subsequent files. However, in
normal circumstances, users would expect the import to stop immediately
upon pressing Ctrl-C.
And because the current file was not finished importing, subsequent
import tasks often fail due to an `unknown ancestor` error.
---------
Signed-off-by: jsvisa <delweng@gmail.com>
Co-authored-by: Felix Lange <fjl@twurst.com>
This ensures that if we receive a blob transaction announcement where we cannot
link the tx to the sidecar commitments, we will drop the sending peer. This check
is added in the protocol handler for the PooledTransactions message.
Tests for this have also been added in the cross-client "eth" protocol test suite.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
This is a not-particularly-important "cleanliness" PR. It removes the
last remnants of the `x/exp` package, where we used the `maps.Keys`
function.
The original returned the keys in a slice, but when it became 'native'
the signature changed to return an iterator, so the new idiom is
`slices.Collect(maps.Keys(theMap))`, unless of course the raw iterator
can be used instead.
In some cases, where we previously collect into slice and then sort, we
can now instead do `slices.SortXX` on the iterator instead, making the
code a bit more concise.
This PR might be _slighly_ less optimal, because the original `x/exp`
implementation allocated the slice at the correct size off the bat,
which I suppose the new code won't.
Putting it up for discussion.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
