am1r021
am1r021
AccountFetcher Capture data now done/part of - https://github.com/ethereumjs/ethereumjs-monorepo/pull/2157 - `getAccountRange` - `getStorageRanges` - `getByteCodes` - `getTrieNodes` My understanding is that there needs to be one fetcher per each `get` call...
This PR adds tests for the getTrieNodes and trieNodes SNAP messages. Real data is captured and used for tests.
Implements `eth_getBlockTransactionCountByNumber` rpc endpoint for #1114.
The aim of this change is to implement a flat database design for keeping state data in. This work will be integrated with the snap sync implementation for keeping snapshots...
During snap sync, if the client requests a range that is both empty and has no elements remaining to the right of it, the peer responds with just a proof....
This PR begins the Prometheus integration work by first adding a Prometheus client server to the ethereumjs client and then adding custom metrics discussed in #3089.
When the client finishes synchronizing the cl skeleton chain, snap sync does not start as expected but rather falls into a defunct hanging state. From internal discussion, it seems like...
Currently, when the EthereumJS client requests accounts using the snap sync `getAccountRange` API call from a Geth client that is not yet synced, it crashes when handling the rejection response:...
Currently, during snap sync, if the client is terminated using `ctr-c`, the `StorageFetcher` attempts to use the database when it's not open: ``` 2024-01-09T01:10:24.786Z client:StorageFetcher Entering nextTasks with primary queue...
This is a tracker ticket for work being done on implementing a flat DB. TODO: - [x] Refactor and integrate `StackTrie` #2980 - [x] Refactor and integrate `Snapshot` - [...