Summary
Some blocks can contain many log entries, which may cause the script to consume large memory or stall when fetching and comparing large arrays. The tool currently fetches all logs for a block, which might be undesirable for very busy contracts or high-volume periods.
Proposed Changes
- Add a CLI flag (e.g.
--max-logs-per-block N) that limits how many logs are fetched per block (e.g. only the first N logs), or skips blocks with excessive logs.
- If limit is set and block exceeds it, either:
- skip that block and warn the user, or
- only fetch first N logs and warn about truncation.
- Document this option and tradeoffs in README.
Motivation
- Avoids excessive memory usage or RPC response overload for large blocks.
- Gives users a way to trade completeness for practicality when auditing massive block ranges or busy contracts.
- Makes tool more robust and usable in real-world heavy-traffic conditions.
Summary
Some blocks can contain many log entries, which may cause the script to consume large memory or stall when fetching and comparing large arrays. The tool currently fetches all logs for a block, which might be undesirable for very busy contracts or high-volume periods.
Proposed Changes
--max-logs-per-block N) that limits how many logs are fetched per block (e.g. only the first N logs), or skips blocks with excessive logs.Motivation