EIP-4844 Blob Transactions Failing on Sepolia After Fusaka Upgrade

[iteyelmp]

Check existing issues

• I checked there isn't already an issue for the bug I encountered.

Viem Version

2.38.2

Current Behavior

After the Fusaka upgrade on Sepolia, sending EIP-4844 transactions fails with the error:

legacy blob tx is not supported

After investigation, it seems that the way blob proofs are computed has changed. Previously, we used compute-blob-kzg-proof, but now it seems we should use compute_cells_and_kzg_proofs.

However, the output of compute_cells_and_kzg_proofs is no longer a single hex string—it returns an array of arrays. This raises a question: do the blob-related fields in the transaction format need to be updated to reflect this new structure?

Requesting clarification or guidance on how EIP-4844 transactions should be constructed post-Fusaka on Sepolia.

Expected Behavior

No response

Steps To Reproduce

No response

Link to Minimal Reproducible Example

No response

Anything else?

No response

[jxom]

Aw man 😭 will look.

[spalladino]

Hey @jxom, we at AztecProtocol/aztec3-packages are interested in this, since our testnet client stopped being able to push blobs after fusaka went in. Is there anything we can do here to help? Or a rough timeline you can share?

[spalladino]

@jxom my guess from looking at alloy-rs code here (thanks to @mattsse for the link) is that the following needs to use compute_cells_and_kzg_proofs from https://github.com/ethereum/c-kzg-4844 as opposed to compute_blob_kzg_proof:

viem/src/utils/blob/blobsToProofs.ts

Line 87 in 5031192

proofs.push(Uint8Array.from(kzg.computeBlobKzgProof(blob, commitment)))

[spalladino]

I've Clauded a fix for this in #4022. I manually ran the src/actions/wallet/sendRawTransaction.test.ts 4844 test against a Sepolia node and it worked successfully. I'm happy to iterate on the PR as needed.

[jxom]

I can take a look when I find some time, but for the meantime, you can use the preview release.

[spalladino]

Thanks @jxom, I ended up publishing a fork here. We've been testing it in our internal test networks and it seems to be working fine on Sepolia.