Release Geth v1.14.10 #30522
Merged
Release Geth v1.14.10 #30522
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
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.
…rollback (#30495) Here we move the method that drops all transactions by temporarily increasing the fee into the TxPool itself. It's better to have it there because we can set it back to the configured value afterwards. This resolves a TODO in the simulated backend.
core/txpool/blobpool: return all reinject-addresses
…ue upon rollback" (#30521) Reverts #30495 You are free to create a proper Clear method if that's the best way. But one that does a proper cleanup, not some hacky call to set gas which screws up logs, metrics and everything along the way. Also doesn't work for legacy pool local transactions. The current code had a hack in the simulated code, now we have a hack in live txpooling code. No, that's not acceptable. I want the live code to be proper, meaningful API, meaningful comments, meaningful implementation.
karalabe
requested review from
fjl,
zsfelfoldi,
lightclient,
s1na,
gballet and
holiman
as code owners
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.
No description provided.