-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[DNM] arbos50+main -> arbos40 #18206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
awskii
wants to merge
388
commits into
arbitrum
Choose a base branch
from
arb0
base: arbitrum
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
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
moved `salt` out of config objects and `dirs` too (not compile-time-known field)
genesis write and state root calc: - it's high-level rare-used logic: mostly `backend.go` calling it - but it's very complex (high-level): creating temporary db, calculating state root, etc... - moving it out of `core` package. because `core` package is low-level - also I moved `ReadChainConfig`/`WriteChainConfig` from `core` to `rawdb` package (In next PR I planing add blockFiles to `temporal.DB` - so, it will manage open/close transactions on this files too - same as currently it does for state files)
move more things to `statecfg` package: - Schema - DomainCfg/IICfg - RegisterDomain calls - AddDependencyBtwnDomains calls - versions about `statecfg` package: all our components have separated cfg package - `txpoolcfg`, `downloadercfg`, `rpccfg`. Because configs: are low-level concept and passing everywhere around APP. Usually such `cfg` packages don't depend on anything big - and have basic types config-types, Default values for configs, constants, etc... Usually `cfg` are known at comp-time (or at least at `init`). `db/kv` aslo as `cfg`-style package - it has configs (`tables.go`) and interfaces.
…ebug` to `dbg` package (#16849)
fixes #16852 checking the `blackListForPruning` was accidentally removed in #16648 diff of Downloader.Add logs (before/after fix): https://www.diffchecker.com/MoE9EsyG/
Co-authored-by: JkLondon <[email protected]>
Co-authored-by: JkLondon <[email protected]>
Co-authored-by: JkLondon <[email protected]>
Co-authored-by: JkLondon <[email protected]>
Main rebase of #16870.
…16863) Co-authored-by: JkLondon <[email protected]>
@yperbasis what do you think? it's `discv4` observer of p2p network to gather statistic and topology. no updates since 2023 and no unit-tests.
Change the channel to a buffered channel with capacity 1. This ensures that the goroutine can always complete the send, even if the caller has already returned due to context cancellation. The response will simply sit in the channel until it is garbage collected, avoiding the leak.
…16823) Switch boundary check from txNum > max to txNum < _min to correctly detect transitions between blocks during descending iteration over history index. This ensures per-block Min/Max are recomputed when crossing into an older block, making the “no system txs” check reliable across the full scan.
The RPC specification for trace_filter includes support for block tags (e.g., 'latest', 'earliest'). Nethermind also supports this feature.
- might solve #16613 - in the issue, timeout happens and so receipt is nil, we still populate the cache, leading to incorrect subsequent calls (also EMPTY is returned, rather than timeout err)
Signed-off-by: jishudashen <[email protected]> Signed-off-by: dependabot[bot] <[email protected]> Signed-off-by: xinhangzhou <[email protected]> Signed-off-by: LesCyber <[email protected]> Signed-off-by: fengyuchuanshen <[email protected]> Signed-off-by: pingshuijie <[email protected]> Co-authored-by: Andrew Ashikhmin <[email protected]> Co-authored-by: canepat <[email protected]> Co-authored-by: sudeepdino008 <[email protected]> Co-authored-by: Ilya Mikheev <[email protected]> Co-authored-by: JkLondon <[email protected]> Co-authored-by: JkLondon <[email protected]> Co-authored-by: antonis19 <[email protected]> Co-authored-by: antonis19 <[email protected]> Co-authored-by: Alex Sharov <[email protected]> Co-authored-by: lupin012 <[email protected]> Co-authored-by: Fibonacci747 <[email protected]> Co-authored-by: awskii <[email protected]> Co-authored-by: Matt Joiner <[email protected]> Co-authored-by: Michelangelo Riccobene <[email protected]> Co-authored-by: Somnath <[email protected]> Co-authored-by: milen <[email protected]> Co-authored-by: Bartosz Zawistowski <[email protected]> Co-authored-by: MozirDmitriy <[email protected]> Co-authored-by: lystopad <[email protected]> Co-authored-by: jishudashen <[email protected]> Co-authored-by: Nikita Ostroukhov <[email protected]> Co-authored-by: Galoretka <[email protected]> Co-authored-by: blxdyx <[email protected]> Co-authored-by: blxdyx <[email protected]> Co-authored-by: Snezhkko <[email protected]> Co-authored-by: Giulio rebuffo <[email protected]> Co-authored-by: Paweł Bylica <[email protected]> Co-authored-by: Kewei <[email protected]> Co-authored-by: Bashmunta <[email protected]> Co-authored-by: Mark Holt <[email protected]> Co-authored-by: mholt-dv <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: alex <[email protected]> Co-authored-by: Shoham Chakraborty <[email protected]> Co-authored-by: RealMaxing <[email protected]> Co-authored-by: Willian Mitsuda <[email protected]> Co-authored-by: Michele Modolo <[email protected]> Co-authored-by: xinhangzhou <[email protected]> Co-authored-by: yperbasis <[email protected]> Co-authored-by: LesCyber <[email protected]> Co-authored-by: Alleysira <[email protected]> Co-authored-by: fengyuchuanshen <[email protected]> Co-authored-by: Torprius <[email protected]> Co-authored-by: Ping Shuijie <[email protected]> Co-authored-by: Forostovec <[email protected]> Co-authored-by: Bartosz Zawistowski <[email protected]> Co-authored-by: awskii <[email protected]>
Arb/merge main2
Update eth_call with blockOverrides according specs and Geth behaviour Included new rpc-tests TAGS with NEW tests
- MmapRw is dead code: there are zero references across the repository. - The API is non-portable: there is no Windows implementation of MmapRw, so introducing usage would break Windows builds. - All current call sites use read-only mapping via Mmap; no write-enabled mapping is needed. - Removing it simplifies the API surface and avoids confusion about supported functionality.
The plan is to raise the limit to 60M around Fusaka. See https://github.com/NethermindEth/eth-perf-research/blob/main/README.md
… timer leak (#17283) ### Summary Replace `time.Tick` with a single `time.NewTicker` in `trackRemovedFiles` and stop it via `defer ticker.Stop()` to avoid leaking timers. ### Rationale `time.Tick` creates a ticker that cannot be stopped; using it directly inside a looped `select` leads to accumulating timers and unnecessary wakeups over time. ### Changes - Create one `time.NewTicker(30 * time.Second)` outside the loop and use `ticker.C`.
Parallel Transaction Implementation (using BSTM validation) This PR contains a working implementation of Block STM based paralelel execution which has been tested on Ethereum and Polygon main nets. The current version achieves 2-3x parallel execution with a re-execution rate of between 20&30% accross the 1-2 Million Blocks synced using it. Below is the processing model used for execution: <img width="943" height="453" alt="Screenshot 2025-08-31 at 18 25 50" src="https://github.com/user-attachments/assets/700d5e90-f42a-494a-8712-65c526055286" /> Transaction executuion tasks run independently and are validated in order when results are returned to the scheduer task. Finalization applies gas calculation, fee distribution and receipt generation as a final post executuoin step. Post finalization Transaction & Block results are sent in order to the main Exec3 worker thread where these results are applied to the underlying shared domain before commitement calculations are performed in either a batch mode or on a block by block basis. Block commitment calculations are used mainly for debugging as they can be associlated with a specific block for further examination. Parallel execution is currently experimental and is enabled by setting the following environment variables prior to running erigon: **ERIGON_EXEC3_PARALLEL**: set 'true' to enable parallel execution **ERIGON_EXEC3_WORKERS**: set to the number of worker threads used to process transactions tasks In addition to these enviroment variables the following variable can be set to true for bor networks to enable reading of dependecy lists from bor mainnet to cuase the parallel scheduler to set the dependencies of exeuction tasls. While this should theoretically increase parallel throughput experimenation with the erigon implementation shows that it actually slows down execution - so it is set false by defualt even if parallel execution is enabled. It is likely that the dependency analyis in bor may be overly conservative - but this requires further analysis. **ERIGON_USE_TX_DEPENDENCIES**: set 'true' to enable reading of header dependencies for bor based chains. In order to aid debugging of state root, receipt root, logging and gas discrepancies the following environment variablles can be used to induce console tracing of the following aspects of the execution process. This logging is necessarily verbose so is only intended to be enables for specific debug runs and is logged to the process std out. It is not intended to be used for logging and appends block and transaction information to the start of every line to facilitate the subsequent use of grep or similar command line tools to filter the output. The following variables control when tracing occurs. It is used to limit output to specific accounts, blocks, transactions. It is useful to avoid overly verbose output on long runs, especilly when detailed tracing is enabled. **ERIGON_TRACE_ACCOUNTS**: A comma seperated list of accounts (case insensative) to be traced (all blocks) **ERIGON_TRACE_STATE_KEYS**: A comma seperated list of state keys (case insensative) to be traced (all blocks) **ERIGON_TRACE_BLOCKS**: A comma seperated list of blocks to be traced (all transactions) **ERIGON_TRACE_TXINDEXES**: A comma seperated list of tx indecies within traced blocks to be traced **ERIGON_STOP_AFTER_BLOCK**: Block number. Block processing will be stopped (and not commited) after this block The following variables control what is traced whentracing is enabled. Typically IO tracing traces operations that happen on IntraBlockState transitions. It is relatively consise although all reads & writes for all tranactions of large blocks can still produce a signifigant amount of output. Instruction tracing produced a trace of EVM instructions which is very verbose, but makes it possible to see the root cuase of logical errors induced by unexpected reads, or instruction ouputs. **ERIGON_TRACE_TRANSACTION_IO**: Provide trace output for transaction read write actions carried out by the processing of intra block state activity. This includes all read & writes + signifigant other activity sutch as account creation and deletion. **ERIGON_TRACE_INSTRUCTIONS**: Provide an instruction level trace of evm exctivity, this includes the program counter, instruction names, arguments and gas costs, it may also include return values. The arguments and return values are present for all signifigant instructions but is incomplete. Missing data can be added by enhancing the instruction stringers that where introduced as part of this work. **ERIGON_TRACE_LOGS**: Trace log production - including evential logs in receipts. **ERIGON_TRACE_GAS**: Trace various aspects of gas and fee calculations. Useful when debugging gas discrepencies. **ERIGON_TRACE_DYNAMIC_GAS**: This provides addition information around how dynamic gas pricing is produced (It may not be entierly accruate but is enough for tracing purposes when investigating mismatches. It may require additional enhancement. **ERIGON_TRACE_APPLY**: this traces the output of the shared domain apply function. It is useful for observing causes of root mismatches as it shows the key updated which will be applied during root calculation. In practice this has been used for debugging the parallel framework and may not be completely useful as is. The following variable can be used to force block level root calculations to happen even when the execution process is in sync mode. When in this mode block level roots will always be calculated and when a root mismatch occurs the process will dump the applied leys for the block along with all block IO activity. This is useful to determine which key is missing from the calculation. These missing keys can then be used with the environment variables above to investigate the break. **BATCH_COMMITMENTS**: when set to 'true' state root calculations happen for each block irrespective of the exec operating mode. Note: To be merged after 3.2 release branch cut. --------- Co-authored-by: dvovk <[email protected]> Co-authored-by: mholt-dv <[email protected]> Co-authored-by: sudeepdino008 <[email protected]>
This reverts commit fe0b2c0.
Arb0 merge main@168c418
It's misleading since the invocation is already a part of `ApplyBeaconRootEip4788`.
As title says - to avoid further crashes in stage headers.
Moving arb specific txn definitions to its own package.
The biggest change is multi-dimensional gas tracking. See: https://blog.arbitrum.io/dynamic-pricing-explainer/
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.