Mithril #1
Open
Mithril #1
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
…reum#31430) This pull request improves the protection mechanism in the txpool for senders with delegation. A sender with either delegation or pending delegation is now limited to a maximum of one in-flight executable transaction, while gapped transactions will be rejected. Reason: If nonce-gapped transaction from delegated/pending-delegated senders can be acceptable, then it's no-longer possible to send another "executable" transaction with correct nonce due to the policy of at most one inflight tx. The gapped transaction will be stuck in the txpool, with no meaningful way to unlock the sender. --------- Co-authored-by: lightclient <[email protected]>
…m#31081) This PR is ethereum#3 of a 3-part series that implements the new log index intended to replace core/bloombits. Based on ethereum#31079 and ethereum#31080 Replaces ethereum#30370 This part removes the old bloombits package and the chain indexer that was only used by bloombits. Deletes the old bloombits database. FilterMaps data structure explanation: https://gist.github.com/zsfelfoldi/a60795f9da7ae6422f28c7a34e02a07e Log index generator code overview: https://gist.github.com/zsfelfoldi/97105dff0b1a4f5ed557924a24b9b9e7 Search pattern matcher code overview: https://gist.github.com/zsfelfoldi/5981735641c956afb18065e84f8aff34 Note that the possibility of a tree hashing scheme and remote proof protocol are mentioned in the documents above but they are not exactly specified yet. These specs are WIP and will be finalized after the local log indexer/filter code is finalized and merged. --------- Co-authored-by: Felix Lange <[email protected]>
In ethereum#31384 we unindex TXes prior to the merge block. However when the node starts up it will try to re-index those back if the config is to index the whole chain. This change makes the indexer aware of the history cutoff block, avoiding reindexing in that segment. --------- Co-authored-by: Gary Rong <[email protected]> Co-authored-by: Felix Lange <[email protected]>
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 <[email protected]>
… reason was not returned (ethereum#31456)
Instead of reporting all filtermaps stuff in one line, I'm breaking it down into the three separate kinds of entries here. ``` +-----------------------+-----------------------------+------------+------------+ | DATABASE | CATEGORY | SIZE | ITEMS | +-----------------------+-----------------------------+------------+------------+ | Key-Value store | Log index filter-map rows | 59.21 GiB | 616077345 | | Key-Value store | Log index last-block-of-map | 12.35 MiB | 269755 | | Key-Value store | Log index block-lv | 421.70 MiB | 22109169 | ``` Also added some other changes to make it easier to debug: - restored bloombits into the inspect output, so we notice if it doesn't get deleted for some reason - tracking of unaccounted key examples
This PR adds an extra condition to the log indexer initialization in order to avoid initializing with block 0 as target head. Previously this caused the indexer to initialize without a checkpoint. Later, when the real chain head was set, it indexed the entire history, then unindexed most of it if only the recent history was supposed to be indexed. Now the init only happens when there is an actual synced chain head and therefore the index is initialized at the most recent checkpoint and only the last year is indexed according to the default parameters. During checkpoint initialization the best available checkpoint is also checked against the history cutoff point and fails if the indexing would have to start from a block older than the cutoff. If initialization fails then the indexer reverts to unindexed mode instead of retrying because the the failure conditions cannot be expected to recover later.
This PR updates beacon checkpoints. The checkpoints are now stored as embedded hex files, in the same format that ethereum#31469 uses.
This commit upgrades the test submodule to latest version: Latest: ethereum/tests@81862e4 Old: ethereum/tests@faf33b4
…api (ethereum#31304) Adds block override fields for beacon block root and withdrawals to the eth_simulateV1. Addresses ethereum#31264
This pull request removes the node copy operation to reduce memory allocation. Key Changes as below: **(a) Use `decodeNodeUnsafe` for decoding nodes retrieved from the trie node reader** In the current implementation of the MPT, once a trie node blob is retrieved, it is passed to `decodeNode` for decoding. However, `decodeNode` assumes the supplied byte slice might be mutated later, so it performs a deep copy internally before parsing the node. Given that the node reader is implemented by the path database and the hash database, both of which guarantee the immutability of the returned byte slice. By restricting the node reader interface to explicitly guarantee that the returned byte slice will not be modified, we can safely replace `decodeNode` with `decodeNodeUnsafe`. This eliminates the need for a redundant byte copy during each node resolution. **(b) Modify the trie in place** In the current implementation of the MPT, a copy of a trie node is created before any modifications are made. These modifications include: - Node resolution: Converting the value from a hash to the actual node. - Node hashing: Tagging the hash into its cache. - Node commit: Replacing the children with its hash. - Structural changes: For example, adding a new child to a fullNode or replacing a child of a shortNode. This mechanism ensures that modifications only affect the live tree, leaving all previously created copies unaffected. Unfortunately, this property leads to a huge memory allocation requirement. For example, if we want to modify the fullNode for n times, the node will be copied for n times. In this pull request, all the trie modifications are made in place. In order to make sure all previously created copies are unaffected, the `Copy` function now will deep-copy all the live nodes rather than the root node itself. With this change, while the `Copy` function becomes more expensive, it's totally acceptable as it's not a frequently used one. For the normal trie operations (Get, GetNode, Hash, Commit, Insert, Delete), the node copy is not required anymore.
…cessList (ethereum#31336) closes ethereum#31335 --------- Co-authored-by: sashabeton <[email protected]>
This removes DB schema for LES related db entries. LES has been non-functional since the merge.
Simple bugfix to include the access-list in the gas-estimation step of the ABI bindings code.
Add support for state overrides in eth_createAccessList. This will make the method consistent with other execution methods. --------- Co-authored-by: Sina Mahmoodi <[email protected]>
eth/catalyst: force sync of txpool before clearing subpools in Rollback
…thereum#31500) This PR changes log indexer error handling so that if an indexing error happens then it disables the indexer and reverts to unindexed more without resetting the database (except in case of a failed database init). Resetting the database on the first error would probably be overkill as a client update might fix this without having to reindex the entire history. It would also make debugging very hard. On the other hand, these errors do not resolve themselves automatically so constantly retrying makes no sense either. With these changes a new attempt to resume indexing is made every time the client is restarted. The PR also fixes ethereum#31491 which originated from the tail indexer trying to resume processing a failed map renderer. --------- Co-authored-by: Felix Lange <[email protected]>
Ignores all hand-built binaries (built with go build, everything built with make is already ignored)
This PR adds `rawdb.SafeDeleteRange` and uses it for range deletion in `core/filtermaps`. This includes deleting the old bloombits database, resetting the log index database and removing index data for unindexed tail epochs (which previously weren't properly implemented for the fallback case). `SafeDeleteRange` either calls `ethdb.DeleteRange` if the node uses the new path based state scheme or uses an iterator based fallback method that safely skips trie nodes in the range if the old hash based state scheme is used. Note that `ethdb.DeleteRange` also has its own iterator based fallback implementation in `ethdb/leveldb`. If a path based state scheme is used and the backing db is pebble (as it is on the majority of new nodes) then `rawdb.SafeDeleteRange` uses the fast native range delete. Also note that `rawdb.SafeDeleteRange` has different semantics from `ethdb.DeleteRange`, it does not automatically return if the operation takes a long time. Instead it receives a `stopCallback` that can interrupt the process if necessary. This is because in the safe mode potentially a lot of entries are iterated without being deleted (this is definitely the case when deleting the old bloombits database which has a single byte prefix) and therefore restarting the process every time a fixed number of entries have been iterated would result in a quadratic run time in the number of skipped entries. When running in safe mode, unindexing an epoch takes about a second, removing bloombits takes around 10s while resetting a full log index might take a few minutes. If a range delete operation takes a significant amount of time then log messages are printed. Also, any range delete operation can be interrupted by shutdown (tail uinindexing can also be interrupted by head indexing, similarly to how tail indexing works). If the last unindexed epoch might have "dirty" index data left then the indexed map range points to the first valid epoch and `cleanedEpochsBefore` points to the previous, potentially dirty one. At startup it is always assumed that the epoch before the first fully indexed one might be dirty. New tail maps are never rendered and also no further maps are unindexed before the previous unindexing is properly cleaned up. --------- Co-authored-by: Gary Rong <[email protected]> Co-authored-by: Felix Lange <[email protected]>
…hereum#32015) Implements the updated gas cost changes introduced in ethereum/EIPs@5cdd751
This PR introduces a flag that enables returning of newly created state objects in the prestateTracer. **Rationale** Having this information is useful because local execution can more easily distinguish between newly created objects and system contracts. --------- Co-authored-by: Sina Mahmoodi <[email protected]>
…um#31427) The prestateTracer had the intention of excluding accounts that were empty prior to execution from the prestate. This was being done only for created contracts. This PR makes it so all such empty accounts are excluded. This behavior is configurable using the `includeEmpty: true` flag introduced in ethereum#31855. --------- Signed-off-by: Ignacio Hagopian <[email protected]> Co-authored-by: Sina Mahmoodi <[email protected]>
This fixes a data race when accessing the `httpConfig.prefix` field. This field can be modified while the server is running through `enableRPC`. The fix is storing the prefix in the handler, which is accessed through the atomic pointer. alternative to ethereum#32035 fixes ethereum#32019
This reverts commit e0cf89e.
When `GetKey` is called, a missing preimage can cause the function to return a `nil` key. This, in turn, makes `account.Storage` persist an incorrect value.
This pull request reduces the threshold for triggering compaction at level0, leading to less compaction debt. This change is helpful in the case of heavy write-load, mitigating the case of heavy write stalls caused by compaction. closes ethereum#31830
Fixes a data race on the `wallets` slice when closing account Manager. At the moment, there is a data race between a go-routine calling the Manager's `Close` function and the background go-routine handling most operations on the `Manager`. The `Manager`'s `wallets` field is accessed without proper synchronization. By moving the closing of wallets from the `Close()` function into the background thread, this issue can be resolved.
fixes the gnark deserialisation --------- Co-authored-by: Felix Lange <[email protected]>
Adds marshaling fuzzing for G1 and G2 to oss-fuzz. Also aligns the behavior of the google library to that of gnark and cloudflare, which only ever read the first 64 / 128 bytes of the input, regardless of how long the input is
closes ethereum#31254 --------- Co-authored-by: Gary Rong <[email protected]>
As ethereum#31769 defined a global hash pool, so we can reuse it, and also remove the unnecessary KeccakState buffering --------- Co-authored-by: Gary Rong <[email protected]>
…thereum#32057) Pulls in cloudflare/bn256#48 to remove usage of R27 and R29 [which are reserved](https://go.dev/doc/asm#arm64).
…reum#32027) Reading a single transaction out of a block shouldn't need decoding the entire body --------- Co-authored-by: Felix Lange <[email protected]> Co-authored-by: Gary Rong <[email protected]>
Since we have the effective gas price in the message, we can compute tip by simply subtracting the basefee. No need to recompute the effective price. --------- Co-authored-by: Felix Lange <[email protected]>
In this pull request, the original `CacheConfig` has been renamed to `BlockChainConfig`. Over time, more fields have been added to `CacheConfig` to support blockchain configuration. Such as `ChainHistoryMode`, which clearly extends beyond just caching concerns. Additionally, adding new parameters to the blockchain constructor has become increasingly complicated, since it’s initialized across multiple places in the codebase. A natural solution is to consolidate these arguments into a dedicated configuration struct. As a result, the existing `CacheConfig` has been redefined as `BlockChainConfig`. Some parameters, such as `VmConfig`, `TxLookupLimit`, and `ChainOverrides` have been moved into `BlockChainConfig`. Besides, a few fields in `BlockChainConfig` were renamed, specifically: - `TrieCleanNoPrefetch` -> `NoPrefetch` - `TrieDirtyDisabled` -> `ArchiveMode` Notably, this change won't affect the command line flags or the toml configuration file. It's just an internal refactoring and fully backward-compatible. --------- Co-authored-by: Felix Lange <[email protected]>
The optimization tried to defer allocating the cache map until it was used for the first time. It's a relic from earlier times, when tries were copied often. This seems unnecessary now, so we can just create the map when the trie is created. --------- Co-authored-by: Felix Lange <[email protected]>
Aligns the marshaling behavior of gnark to google and cloudflare Co-authored-by: kevaundray <[email protected]>
…2066) This PR improves the IsOnCurve methods for BN254 G2 points by: * Clarifying its behavior the docstring, making it explicit that it verifies both the point being on the curve and in the correct subgroup. * Adding an in-line comment explaining the subgroup membership check (c.Mul(Order)). * Minor wording adjustments for readability and consistency.
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.