Hello #11
Open
Hello #11
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add `quic` entry to the ENR as proposed in ethereum/consensus-specs#3644 --------- Co-authored-by: lightclient <lightclient@protonmail.com>
Signed-off-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com>
This situation(`len(txs) == 0`) rarely occurs, but if it does, it will panic. --------- Co-authored-by: Martin HS <martin@swende.se>
Continuation of #28546
This change makes the code slightly easier for downstream-projects to extend with more signer-types, but if functionalily equivalent to the previous code.
- preallocate capacity for map - avoid `reinject` adding empty value - use `maps.Copy`
Balance being null causes `getGenesisState` to fail as the balance field is required in json marshaling of an account.
After this PR, #28187, the way to set the default logger is different. This PR only updates the way to set logger in some test cases' comments that existed in the codebase (since this commit b63e3c37a6). Although I am not sure if it a good way to leave the code in the comment, it truly makes me more efficiently to debug and fix the failing test cases.
…30069) This PR integrates witness-enabled block production, witness-creating payload execution and stateless cross-validation into the `engine` API. The purpose of the PR is to enable the following use-cases (for API details, please see next section): - Cross validating locally created blocks: - Call `forkchoiceUpdatedWithWitness` instead of `forkchoiceUpdated` to trigger witness creation too. - Call `getPayload` as before to retrieve the new block and also the above created witness. - Call `executeStatelessPayload` against another client to cross-validate the block. - Cross validating locally processed blocks: - Call `newPayloadWithWitness` instead of `newPayload` to trigger witness creation too. - Call `executeStatelessPayload` against another client to cross-validate the block. - Block production for stateless clients (local or MEV builders): - Call `forkchoiceUpdatedWithWitness` instead of `forkchoiceUpdated` to trigger witness creation too. - Call `getPayload` as before to retrieve the new block and also the above created witness. - Propagate witnesses across the consensus libp2p network for stateless Ethereum. - Stateless validator validation: - Call `executeStatelessPayload` with the propagated witness to statelessly validate the block. *Note, the various `WithWitness` methods could also *just be* an additional boolean flag on the base methods, but this PR wanted to keep the methods separate until a final consensus is reached on how to integrate in production.* --- The following `engine` API types are introduced: ```go // StatelessPayloadStatusV1 is the result of a stateless payload execution. type StatelessPayloadStatusV1 struct { Status string `json:"status"` StateRoot common.Hash `json:"stateRoot"` ReceiptsRoot common.Hash `json:"receiptsRoot"` ValidationError *string `json:"validationError"` } ``` - Add `forkchoiceUpdatedWithWitnessV1,2,3` with same params and returns as `forkchoiceUpdatedV1,2,3`, but triggering a stateless witness building if block production is requested. - Extend `getPayloadV2,3` to return `executionPayloadEnvelope` with an additional `witness` field of type `bytes` iff created via `forkchoiceUpdatedWithWitnessV2,3`. - Add `newPayloadWithWitnessV1,2,3,4` with same params and returns as `newPayloadV1,2,3,4`, but triggering a stateless witness creation during payload execution to allow cross validating it. - Extend `payloadStatusV1` with a `witness` field of type `bytes` if returned by `newPayloadWithWitnessV1,2,3,4`. - Add `executeStatelessPayloadV1,2,3,4` with same base params as `newPayloadV1,2,3,4` and one more additional param (`witness`) of type `bytes`. The method returns `statelessPayloadStatusV1`, which mirrors `payloadStatusV1` but replaces `latestValidHash` with `stateRoot` and `receiptRoot`.
This is a work-around for a strange issue with travis, specifically, `os=osx, go: 1.23.1`. When this is used, the actual go that ends up being used is `go1.19.4 darwin/amd64 `. Using `which go`, it told me that the `go` in the path was a softlink at `/Users/travis/gopath/bin/go1.23.1 `. However, this was not true: using `command -v go`, it told me that the actual `go` that was used is a softlink at `/usr/local/bin/go`. This change rewrites the `/usr/local/bin/go` softlink to point to the binary at `/Users/travis/gopath/bin/go1.23.1`, so we get the right go-version.
Make `setEtherbase` fall thorugh and handle `miner.pending.feeRecipient` after showing deprecation-warning for `miner.etherbase`-flag.
This pull request skips the state snapshot update if the base layer is not existent, eliminating the numerous warning logs after an unclean shutdown. Specifically, Geth will rewind its chain head to a historical block after unclean shutdown and state snapshot will be remained as unchanged waiting for recovery. During this period of time, the snapshot is unusable and all state updates should be ignored/skipped for state snapshot update.
This change exits with error if user provided a `--state.scheme` which is neither `hash` nor `path`
Extends the opcontext interface to include accessor for code being executed in current context. While it is possible to get the code via `statedb.GetCode`, that approach doesn't work for initcode.
This change adds more comprehensive benchmarks with a wider-variety of input sizes for g1 and g2 multi exponentiation.
…de (#31012) Co-authored-by: Felix Lange <fjl@twurst.com>
- it was failing because the maximum data length (previously `dataSize`) was set to `txMaxSize - 213` but should had been `txMaxSize - 103` and the last call `dataSize+1+uint64(rand.Intn(10*txMaxSize)))` would sometimes fail depending on rand.Intn. - Maximal transaction data size comment (invalid) replaced by code logic to find the maximum tx length without its data length - comments and variable naming improved for clarity - 3rd pool add test replaced to add just 1 above the maximum length, which is important to ensure the logic is correct
This pull request refactors the genesis setup function, the major changes are highlighted here: **(a) Triedb is opened in verkle mode if `EnableVerkleAtGenesis` is configured in chainConfig or the database has been initialized previously with `EnableVerkleAtGenesis` configured**. A new config field `EnableVerkleAtGenesis` has been added in the chainConfig. This field must be configured with True if Geth wants to initialize the genesis in Verkle mode. In the verkle devnet-7, the verkle transition is activated at genesis. Therefore, the verkle rules should be used since the genesis. In production networks (mainnet and public testnets), verkle activation always occurs after the genesis block. Therefore, this flag is only made for devnet and should be deprecated later. Besides, verkle transition at non-genesis block hasn't been implemented yet, it should be done in the following PRs. **(b) The genesis initialization condition has been simplified** There is a special mode supported by the Geth is that: Geth can be initialized with an existing chain segment, which can fasten the node sync process by retaining the chain freezer folder. Originally, if the triedb is regarded as uninitialized and the genesis block can be found in the chain freezer, the genesis block along with genesis state will be committed. This condition has been simplified to checking the presence of chain config in key-value store. The existence of chain config can represent the genesis has been committed.
We still need to decide how to handle non-specfic `chainId` in the JSON encoding of authorizations. With `chainId` being a uint64, the previous implementation just used value zero. However, it might actually be more correct to use the value `null` for this case.
According to https://github.com/ethereum/execution-apis/blob/main/src/engine/prague.md#engine_newpayloadv4: > Elements of the list MUST be ordered by request_type in ascending order. Elements with empty request_data MUST be excluded from the list. --------- Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
This changes the SenderCacher so its goroutines will only be started on first use. Avoids starting them when package core is just imported but core.BlockChain isn't used.
…uct (#31007) Co-authored-by: Sina M <1591639+s1na@users.noreply.github.com>
This pull request delivers the new version of the state history, where the raw storage key is used instead of the hash. Before the cancun fork, it's supported by protocol to destruct a specific account and therefore, all the storage slot owned by it should be wiped in the same transition. Technically, storage wiping should be performed through storage iteration, and only the storage key hash will be available for traversal if the state snapshot is not available. Therefore, the storage key hash is chosen as the identifier in the old version state history. Fortunately, account self-destruction has been deprecated by the protocol since the Cancun fork, and there are no empty accounts eligible for deletion under EIP-158. Therefore, we can conclude that no storage wiping should occur after the Cancun fork. In this case, it makes no sense to keep using hash. Besides, another big reason for making this change is the current format state history is unusable if verkle is activated. Verkle tree has a different key derivation scheme (merkle uses keccak256), the preimage of key hash must be provided in order to make verkle rollback functional. This pull request is a prerequisite for landing verkle. Additionally, the raw storage key is more human-friendly for those who want to manually check the history, even though Solidity already performs some hashing to derive the storage location. --- This pull request doesn't bump the database version, as I believe the database should still be compatible if users degrade from the new geth version to old one, the only side effect is the persistent new version state history will be unusable. --------- Co-authored-by: Zsolt Felfoldi <zsfelfoldi@gmail.com>
This PR replaces the iterator based DeleteRange implementation of memorydb with a simpler and much faster loop that directly deletes keys in the order of iteration instead of unnecessarily collecting keys in memory and sorting them. --------- Co-authored-by: Martin HS <martin@swende.se>
This PR addresses issue #30768 , which highlights that running cmd/abigen/abigen --pkg my_package example.json (erroneously omitting the --abi flag) generates an empty binding, when it should fail explicitly. --------- Co-authored-by: jwasinger <j-wasinger@hotmail.com>
Use zero value check for the pragueSigner This aligns with cancunSigner and londonSigner as well.
…1030) if the pool terminates before `resetDone` can be read, then the go-routine will hang.
As part of trying to make the inputs and outputs of the evm subcommands more streamlined and aligned, this PR modifies how `evm t8n` manages output-files. Previously, we do a kind of wonky thing where between each transaction, we invoke a `getTracer` closure. In that closure, we create a new output-file, a tracer, and then make the tracer stream output to the file. We also fiddle a bit to ensure that the file becomes properly closed. It is a kind of hacky solution we have in place. This PR changes it, so that from the execution-pipeline point of view, we have just a regular tracer. No fiddling with re-setting it or closing files. That particular tracer, however, is a bit special: it takes care of creating new files per transaction (in the tx-start-hook) and closing (on tx-end-hook). Also instantiating the right type of underlying tracer, which can be a json-logger or a custom tracer. --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com>
) Discovered from failing test introduced #31033 . We should ensure `timeoutLoop` terminates if the filter event system is terminated.
We have our own system for downloading the toolchain, and really don't want Go's to get in the way of that. We may switch to Go's builtin toolchain support, but not now.
Refactoring of the `evm` command moved where some commands were valid. One command, `--bench`, used to work in `evm statetest`. The pluming is still in place. This PR puts the `--bench` flag in the place the trace flags were moved, and adds tests to validate the bench flag operates in `run` and `statetest` --------- Co-authored-by: Felix Lange <fjl@twurst.com>
This is an alternative for #27407 with a solution based on gencodec. With the PR, one can now configure like this: ``` # config.toml [Node.P2P] NAT = "extip:33.33.33.33" ``` ```shell $ geth --config config.toml ... INFO [01-17|16:37:31.436] Started P2P networking self=enode://2290...ab@33.33.33.33:30303 ```
State history v2 has been shipped and will take effect after the Cancun fork. However, the state revert function does not differentiate between v1 and v2, instead blindly using the storage map key for state reversion. This mismatch between the keys of the live state set and the state history can trigger a panic: `non-existent storage slot for reverting`. This flaw has been fixed in this PR.
This PR uses various tweaks and tricks to make the stacktrie near
alloc-free.
```
[user@work go-ethereum]$ benchstat stacktrie.1 stacktrie.7
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/trie
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
│ stacktrie.1 │ stacktrie.7 │
│ sec/op │ sec/op vs base │
Insert100K-8 106.97m ± 8% 88.21m ± 34% -17.54% (p=0.000 n=10)
│ stacktrie.1 │ stacktrie.7 │
│ B/op │ B/op vs base │
Insert100K-8 13199.608Ki ± 0% 3.424Ki ± 3% -99.97% (p=0.000 n=10)
│ stacktrie.1 │ stacktrie.7 │
│ allocs/op │ allocs/op vs base │
Insert100K-8 553428.50 ± 0% 22.00 ± 5% -100.00% (p=0.000 n=10)
```
Also improves derivesha:
```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
│ derivesha.1 │ derivesha.2 │
│ sec/op │ sec/op vs base │
DeriveSha200/stack_trie-8 477.8µ ± 2% 430.0µ ± 12% -10.00% (p=0.000 n=10)
│ derivesha.1 │ derivesha.2 │
│ B/op │ B/op vs base │
DeriveSha200/stack_trie-8 45.17Ki ± 0% 25.65Ki ± 0% -43.21% (p=0.000 n=10)
│ derivesha.1 │ derivesha.2 │
│ allocs/op │ allocs/op vs base │
DeriveSha200/stack_trie-8 1259.0 ± 0% 232.0 ± 0% -81.57% (p=0.000 n=10)
```
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
…ger Flex (#31004) The latest firmware for Ledger Nano S Plus now returns `0x5000` for it's product ID, which doesn't match any of the product IDs enumerated in `hub.go`. This PR removes the assumption about the interfaces exposed, and simply checks the upper byte for a match. Also adds support for the `0x0007` / `0x7000` product ID (Ledger Flex).
Reference: - Remove MUL precompiles: ethereum/EIPs#8945 - Pricing change for pairing operation: ethereum/EIPs#9098 - Pricing change for add, mapping and mul operations: ethereum/EIPs#9097 - Pricing change for MSM operations: ethereum/EIPs#9116 --------- Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de>
This implements a basic mechanism to query the node's external IP using a STUN server. There is a built-in list of public STUN servers for convenience. The new detection mechanism must be selected explicitly using `--nat=stun` and is not enabled by default in Geth. Fixes #30881 --------- Co-authored-by: Felix Lange <fjl@twurst.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Open