Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: Tx delayer hashes do not match when submitting blob txs #10824

Open
spalladino opened this issue Dec 17, 2024 · 1 comment
Open

bug: Tx delayer hashes do not match when submitting blob txs #10824

spalladino opened this issue Dec 17, 2024 · 1 comment
Labels
T-fix Type: fix this. Not quite a bug.

Comments

@spalladino
Copy link
Collaborator

spalladino commented Dec 17, 2024

The tx delayer computes the hash of a tx manually to return it to the caller. However, the hash it computes and the hash it receives from anvil once it's actually submitted do not match. Tested it with the latest version of anvil and still happens, need to figure out whether this is an issue with viem, anvil, or how we're computing the hash manually.

For reference, we're computing tx hash using the input from sendRawTx directly:

const { serializedTransaction } = args[0];
const txHash = keccak256(serializedTransaction);

And that txHash does not match the response from anvil when we actually call sendRawTx on it with the serializedTransaction.

See here for a run where it happens consistently.

@spalladino spalladino added the T-fix Type: fix this. Not quite a bug. label Dec 17, 2024
ludamad added a commit that referenced this issue Dec 17, 2024
Attempts two fixes at e2e epochs test. First, it increases the L1 block
time, to account for general CI slowness. Second, it adds more retries
to the L1 gas utils getTx, since the e2e epochs test works using the tx
delayer, which artificially introduces a delay between a tx being sent
and it being available in anvil, so it triggered a timeout in the utils.

**Update**: Increasing the retries caused the error to change, we were
getting a timeout in teardown. This was caused because the sequencer got
stuck in waiting for the tx to be mined for way too long (more than 5
minutes, the afterAll hook timeout), and the `node.stop()` waits for the
current loops to end before returning.

But what's interesting is _why_ the sequencer got stuck in waiting for
its tx to be mined. The tx was being delayed by the tx-delayer, which
intercepts txs, manually computes their tx hash to return it to the
caller immediately, and holds on the tx to submit it to anvil at a later
point in time. What came up is that the tx hash we were manually
computing over txs with blobs did not match the tx hash returned by
anvil. This has been logged as #10824. However, we can sidestep this
issue by just choosing a reasonable value for max attempts so teardown
doesn't timeout.

---------

Co-authored-by: ludamad <adam.domurad@gmail.com>
@spalladino
Copy link
Collaborator Author

Comment by @MirandaWood:

I think it's viem's serialisation. It appends the blobs, commitments, and proofs if they are available to the serialized tx, but those are not included in the tx hash AFAIK. I managed to recreate one correct tx hash by manually serialising it without the extra bits and hashing it. If viem's version of these extras are fixed size, we can probably just cut off the end of serializedTransaction in tx delayer to find the tx hash, otherwise it might get tricky (edited)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-fix Type: fix this. Not quite a bug.
Projects
None yet
Development

No branches or pull requests

1 participant