Closed Ivan-Feofanov closed 3 weeks ago
We are experiencing the same issue on chain ID 11155111 and address 0xed9a921a8644538e97b4148cf28ccea8e925d52d12f13176dab9314a9fd9e6a4. Is there any update on this issue? Way to reproduce: https://github.com/rumblefishdev/edr-issues-543-reproduce
Hi folks. Sadly, fixing this is not as straightforward as we thought. The changes suggested by @Ivan-Feofanov do seem to work, but have something like a ~15% impact on performance in our benchmarks.
What I'm starting to wonder is if the underlying problem here is that we don't support a lot of different tracers for debug_traceTransaction
. The default opcode
tracer can generate these massive (>500MB) objects, and I suspect that most people don't want that level of detail.
For those who are running into this problem: would your underlying problem be fixed if we supported other tracers, like callTracer
? If so, which ones?
We'll still explore if there's a performant way to support the opcode
tracer for huge transactions, but it might need some bigger changes, or be blocked altogether by some architectural changes we'll make in the future.
@fvictorio we actually use opcode tracer to make EVM Debugger (https://www.rumblefish.dev/evm-debugger/) work. Interestingly, we started working on this way before the fork chain feature was rewritten in Rust. In old Typescript implementation there was also a problem with huge traces. If I remember correctly it didn't work because it was trying to JSON.stringify this massive object that sometimes was like 1gb of text. What we ended up doing on our end is to fork this representions and hook ourselves to event emitted while structlogs were created. We've changed the encoding of http response to chunked encoding and this allowed us to stringify chunks of structlogs and release memory in the process. I understand that it was fairly easier on Typescript than in Rust thanks to the dynamic nature of this language. I'm mentioning this as a suggestion of how possibly this problem could be mitigated. So instead of giving response, return something like a generator
We fixed the issue in EDR and will release a new version and integrate it in Hardhat soon.
We've released EDR v0.5.1 with a fix for this issue.
To upgrade to the latest EDR version immediately, you can remove your node_modules
directory and npm/yarn/pnpm lock file and reinstall your dependencies. Otherwise you can wait for the next Hardhat release which will automatically use the latest EDR version.
You can verify that you’re using the latest version of EDR by running the following command: npm ls @nomicfoundation/edr
.
Hi guys. I'm getting this error when I'm trying to get traces for a big transaction.
Steps to represent
Install the latest hardhat
Run hardhat node as a mainnet fork. Config:
Run:
Make request
Response:
When I'm trying to use a smaller transaction, everything works fine.
Works with
0xce8f47c3c6e0dc401dbbd6ad640bd039362eded9d2a6767f03c7229118eb66bd
Fails with0x7e460f200343e5ab6653a8857cc5ef798e3f5bea6a517b156f90c77ef311a57c