Merged
Conversation
* Some requests may lead to undefined behaviour this will make sure to call .Close once
…gontech#9018) During testing we run into a "span 7813 not found (db)" due to a very large unwind (1 million blocks). This is because the block reader's `LastFrozenSpanID` and `LastFrozenEventID` returned results that are not consistent with `FrozenBorBlocks`. The latter is taking into account the existence of `.idx` files while the former 2 functions were not. Note such a large unwind is not likely to happen normally unless there is a bug in our unwind logic or an operator is manually unwinding very far back due to reasons like chain halts (ie mumbai bug problem from few months ago), devel testing or anything else along these lines. Regardless, it exposed the above discrepancy which is best to be fixed.
…ch#9020) Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.16.0 to 0.17.0. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/golang/crypto/commit/9d2ee975ef9fe627bf0a6f01c1f69e8ef1d4f05d"><code>9d2ee97</code></a> ssh: implement strict KEX protocol changes</li> <li><a href="https://github.com/golang/crypto/commit/4e5a26183ecb4f9a0f85c8f8dbe7982885435436"><code>4e5a261</code></a> ssh: close net.Conn on all NewServerConn errors</li> <li><a href="https://github.com/golang/crypto/commit/152cdb1503ebc13bc0fbb68f92ee189ebf9e3d00"><code>152cdb1</code></a> x509roots/fallback: update bundle</li> <li><a href="https://github.com/golang/crypto/commit/fdfe1f8531a1adcc300c8eba98cb372044826d62"><code>fdfe1f8</code></a> ssh: defer channel window adjustment</li> <li><a href="https://github.com/golang/crypto/commit/b8ffc16e10063067bac0e15c6d7f7995937503ce"><code>b8ffc16</code></a> blake2b: drop Go 1.6, Go 1.8 compatibility</li> <li><a href="https://github.com/golang/crypto/commit/7e6fbd82c804e1760feb603fe21caecb0af0a124"><code>7e6fbd8</code></a> ssh: wrap errors from client handshake</li> <li><a href="https://github.com/golang/crypto/commit/bda2f3f5cfce3f27039acccd823693f6d67c2a74"><code>bda2f3f</code></a> argon2: avoid clobbering BP</li> <li>See full diff in <a href="https://github.com/golang/crypto/compare/v0.16.0...v0.17.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/ledgerwatch/erigon/network/alerts). </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Gnosis phase2 will be disabled until we get good snapshot automation. * Just run it in "phase1" mode. * Create jwt secret accordingly
Sync from scratch took about 4 days 15 hours, with total disk used about 2.8TB ``` ubuntu@localhost:/erigon$ cast block-number 18825796 ubuntu@localhost:/erigon$ ls chaindata downloader jwt.hex LOCK nodekey nodes snapshots temp txpool ubuntu@localhost:/erigon$ du -hs chaindata 2.2T chaindata ubuntu@localhost:/erigon$ du -hs downloader 17M downloader ubuntu@localhost:/erigon$ du -hs snapshots 473G snapshots ubuntu@localhost:/erigon$ du -hs temp 79G temp ```
…ads.lock file (erigontech#9036) it will protect existing nodes from downloading `v2` files - even if they do upgrade
…erigontech#9012) `e35` doesn't write genesis state by special func anymore - and Mock using `m.InsertBlocks` to process genesis block (as any other block).
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>
First "smoke test", to check Erigon clean exiting on ctrl-c
erigon didn't download form webseeds if StageSnapshots progress > 0. but sometime we want "just delete files and re-download them"
…ntech#9054) Found the different log style for announced and broadcasted tx: ``` [INFO] [12-22|05:18:01.363] Local tx broadcasted txHash=ec6b1c87aafd7f8ead5794477be50bda696f2ce17271ad4f6022a756722fa0be to peer=10 [INFO] [12-22|05:18:01.363] local tx announced tx_hash=ec6b1c87aafd7f8ead5794477be50bda696f2ce17271ad4f6022a756722fa0be to peer=40 baseFee=1 ``` adjust them to the same style Signed-off-by: jsvisa <delweng@gmail.com>
`STAGES_ONLY_BLOCKS=true` may help to produce BlockSnaps by Erigon2 on weak machines - it disabling all stages after StageSenders.
Co-authored-by: battlmonstr <battlmonstr@users.noreply.github.com>
Add paths to the hiemdall config URL when creating calls so that extra paths needs by, for example proxy servers are not stripped from the flag value passed into the process.
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>
This PR is ready to review. PR introduces `blocksByRange` and `blocksByRoot` P2P RPC methods - `blocksByRange` - allows peers to request a range of blocks - `blocksByRoot` - enables block requests using their root hashes(list format) Reference: https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#beaconblocksbyrange
This was noticed when running a hive test targeted at failing when there are no versioned hashes in the tx
Bor execution relies on sync events produced by the sync events loaded during the bor heimdall stage. This fix makes sure that ther bodies and hence execution stage do not progress further than the current progress of bor heimdall to avoid missing these events.
Delete destination chaindata before rsyncing to avoid "No space left on device"
Now we are not Epochs-constrained anymore.
## Lists of Bugs found (and fixed) * version in wrong format. * Avoid crash in validators endpoint * Fixed formatting in the archive node sanitizer * Tracking MetadataV2/MetadataV1/Ping with DiscV5. * More relevant responses to Status and MetadataV2/V1
This PR add support to optionally use a local `silkworm-go` repo during development. If not available, a temporary repo clone is used as before. The typical setup we use during Silkworm-for-Erigon development is described [here](https://github.com/erigontech/silkworm/blob/master/docs/CONTRIBUTING.md#c-api-for-erigon).
**Summary** Adds a new flag/parameter `totalBlobPoolLimit` to the txpool. Any time the number of blobs (total of all blobs in all type-3 txs) exceeds this number, the pool won't accept any more blob txs. This is a very straightforward way to prevent blob spamming. It also gives a node operator the freedom to stay away from too many blobs in their own pool. **More background**: Blob txs take a huge toll on the txpool and the rest of the system because of their size and cryptography involved.
```
[INFO] [02-08|22:58:28.974] new subscription to logs established
[INFO] [02-08|22:58:28.975] rpc filters: subscribing to Erigon events
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x240 pc=0x122572f]
goroutine 2343 [running]:
github.com/ledgerwatch/erigon/consensus/misc.eip1559Calculator.CurrentFees({}, 0xc046591900, {0x7f1202466db8, 0xc0341b7d40})
github.com/ledgerwatch/erigon/consensus/misc/eip1559.go:80 +0xcf
github.com/ledgerwatch/erigon-lib/txpool.(*TxPool).fromDB(0xc000936c80, {0x3277f60, 0xc000cd8eb0}, {0x3299818?, 0xc0341b7ce0}, {0x3299818?, 0xc0341b7d40?})
github.com/ledgerwatch/erigon-lib@v1.0.0/txpool/pool.go:2095 +0x8b3
github.com/ledgerwatch/erigon-lib/txpool.(*TxPool).Start.func1({0x3299818, 0xc0341b7ce0})
github.com/ledgerwatch/erigon-lib@v1.0.0/txpool/pool.go:329 +0xfe
github.com/ledgerwatch/erigon-lib/kv/mdbx.(*MdbxKV).View(0x29e8d60800?, {0x3277f60?, 0xc000cd8eb0?}, 0xc03412f7a0)
github.com/ledgerwatch/erigon-lib@v1.0.0/kv/mdbx/kv_mdbx.go:749 +0xa6
github.com/ledgerwatch/erigon-lib/txpool.(*TxPool).Start(0xc000936c80, {0x3277f60?, 0xc000cd8eb0}, {0x328d2d0, 0xc0161ad0a0})
github.com/ledgerwatch/erigon-lib@v1.0.0/txpool/pool.go:319 +0xc9
github.com/ledgerwatch/erigon-lib/txpool.MainLoop({0x3277f60?, 0xc000cd8eb0}, {0x328d2d0, 0xc0161ad0a0}, 0xc000936c80, 0xc0340750e0, 0xc017e1e0a0, 0xc034088c60, 0xc03459f190)
github.com/ledgerwatch/erigon-lib@v1.0.0/txpool/pool.go:1729 +0x205
created by github.com/ledgerwatch/erigon/eth.New
github.com/ledgerwatch/erigon/eth/backend.go:718 +0x3fbd
```
…tech#9393) Bugs fixed: * CurrentEpochAttestations misbehaviour near genesis. * Fixed Participation indices at the Altair Fork Boundary. * Confusing logs demoted to DBUG * Added 6 slots of margin of error for the forward downloader * Fixed nil exception in exits processing * Keep 1 state in the hot storage for reorgs at all costs * Fixed `make len: out range`
…ncun check (erigontech#9413) This PR fixes erigontech#9407
Fixed Caplin Archive node post-deneb
I've found broken link to gnosis docs, this PR fixes the issue.
Fix for: fatal error: concurrent map read and map write goroutine 213 [running]: github.com/ledgerwatch/erigon-lib/downloader.initSnapshotLock.func1() github.com/ledgerwatch/erigon-lib@v1.0.0/downloader/downloader.go:329 +0x3a7
This fix avoid a potential hanging file close for tests which use !cfg.SnapshotLock to allow the creation of arbitary files for tests and hence want to avoid the lock
In certain scenarios (e.g. Hive) genesis is initially populated by `erigon init` and afterwards erigon is started with some `networkid` flag, typically != 1. In that case it's incorrect to use default (mainnet) genesis instead of reading genesis from the DB. This PR fixes Issue erigontech#9191 and also some Hive tests that were incorrectly returning `SYNCING` because they were trying to download mainnet snapshots.
…rigontech#9434) Cherry pick PR erigontech#9429 Co-authored-by: Somnath <snb895@outlook.com>
Cherry pick PR erigontech#9433 Co-authored-by: Somnath <snb895@outlook.com>
Cherry pick PR erigontech#9435 --------- Co-authored-by: Alex Sharov <AskAlexSharov@gmail.com>
Cherry pick erigontech#9474 --------- Co-authored-by: Alex Sharov <AskAlexSharov@gmail.com>
The method was iterating over snapshots.segments.Min().segments, but passing the index to view.Segments(). This might lead to a crash, because those 2 collections are different, and the indexes might not match. view.Segments() only contains the snapshot files that are fully downloaded and indexed. The code is changed to only use the view files (as it was before).
…h#9674) Cherry pick PR erigontech#9603 Block number: 54876000 (March 20th, 2024 at around 10.30 AM UTC) --------- Co-authored-by: Manav Darji <manavdarji.india@gmail.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.