Testing erc-4337 user operations with Hardhat node

[TSKHot]

Hi. I had a ticket raised and answered on the Discord server, but it's disappeared and I've lost the answer. (The whole discord server seems to be inactive ... ??)

We are coding to erc-4337, using Stackup bundler. When a user operation is submitted it is initially simulated and reverted as per 4337.

However, as far as we can see, hardhat is wrapping the evm revert output in a string which means the bundler doesn't correctly interpret the expected revert output and the operation fails.

How can we configure hardhat to return the raw evm output for testing erc-4337 behaviour?

[fvictorio]

Hi @TSKHot, could you specify, at the JSON-RPC layer, what kind of responses you get from production nodes like geth, and what you get from Hardhat?

[TSKHot]

Hi @fvictorio,

Having looked into it more deeply, it appears we misschractarised the response from Hardhat - it's not that it's wrapping the reverts in a string, rather it appears to be wrapping the json response in another json response.

From Geth, it seems that something like the following is returned:
{
"Code": 3,
"Message": "execution reverted",
"Data": "0x8b7ac980000000000000000000000000000000000000000000000000000000000018c9a6000000000000000000000000000000000000000000000000000000000175153800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000000"
}

whereas from Hardhat, it seems that something like the following is returned:
{
"Code": -32603,
"Message": "Error: VM Exception while processing transaction: reverted with an unrecognized custom error (return data: 0x8b7ac980000000000000000000000000000000000000000000000000000000000018c73b0000000000000000000000000000000000000000000000000005efbb914b9d0c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000000)",
"Data": {
"message": "Error: VM Exception while processing transaction: reverted with an unrecognized custom error (return data: 0x8b7ac980000000000000000000000000000000000000000000000000000000000018c73b0000000000000000000000000000000000000000000000000005efbb914b9d0c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000000)",
"data": "0x8b7ac980000000000000000000000000000000000000000000000000000000000018c73b0000000000000000000000000000000000000000000000000005efbb914b9d0c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000000"
}
}

I think it would be good if there was a config option in Hardhat to return the exact raw response.

However, we're continuing to dig into it and if we discover more detail we'll add it here.

[TSKHot]

We can change the Stackup Bundler code locally to unwrap the responses appropriately, however there's a more serious problem.

Hardhat only has a default tracer for debug_traceCall and Stackup is requesting to use "BundlerCollectorTracer" which Geth provides.

Are there any plans to implement this tracer in Hardhat?

[fvictorio]

Hey @TSKHot, sorry for the super late response.

I think it would be good if there was a config option in Hardhat to return the exact raw response.

The JSON-RPC layer is extremely underspecified for things like this. We could add an option to make it more geth compatible, but it's unclear if it's worth it given that everyone seems to do whatever they want. I think most tools that rely on the response return data that I've seen just deal with this in a dynamic way. It's far from ideal, but in general I prefer to avoid adding options unless it's absolutely necessary.

Are there any plans to implement this tracer in Hardhat?

Not right now. I don't think we even have an issue about this, the closest we have is one about adding custom js tracers (#4234). Could you please open an issue with that feature request?

[TSKHot]

Hey @fvictorio . Thanks for getting back to me. I've added a feature request to the issue list - #7103.