Issues encoding eip-4844 transaction.

[noahfigueras]

While trying to send an eip-4844 transaction with send_raw_transaction(), I've been running into several RLP encoding errors when submitting to rpc endpoint. Error: Server returned an error response: error code -32000: rlp: expected List

 use alloy_providers::provider::{ Provider, TempProvider };
use alloy_signer::{LocalWallet, SignerSync, Signer, Transaction };
use alloy_primitives::{U256, address, bytes, B256, Bytes, FixedBytes };
use alloy_consensus::{ 
    TxEip4844, 
    TxEnvelope, 
    BlobTransactionSidecar, 
    TxEip4844WithSidecar,
    TxEip4844Variant
};
use alloy_eips::eip2718::Encodable2718;
use alloy_transport_http::Http;
use alloy_eips::eip2930::AccessList;
use alloy_rlp::{
    RlpEncodable, 
    BufMut, 
    Decodable, 
    Encodable, 
    Rlp, 
    Header,
    length_of_length
};
use std::env;
use kzg::{ 
    Blob, 
    Bytes48, 
    BYTES_PER_BLOB, 
    BYTES_PER_COMMITMENT,
    BYTES_PER_PROOF,
    Kzg, 
    TrustedSetup,
    KzgProof,
};
use std::fs;
use eyre::Result;
use serde_json::from_str;

#[derive(Clone, Debug, RlpEncodable)]
struct SideCar {
    blobs: Vec<[u8; BYTES_PER_BLOB]>,
    commitments: Vec<[u8; BYTES_PER_COMMITMENT]>, 
    proofs: Vec<[u8; BYTES_PER_PROOF]>,
}

impl SideCar {
    fn fields_len(&self) -> usize {
        let mut len = 0;
        len += self.blobs.length();
        len += self.commitments.length();
        len += self.proofs.length();
        len
    }
}

#[tokio::main]
async fn main() -> Result<()>{
    let rpc_url: &str = env!("RPC_URL");
    let pk: &str = env!("PK");
    let data = fs::read_to_string("./trusted_setup.json")
        .expect("Unable to read file");
    let trusted_setup: TrustedSetup = from_str(&data)
        .expect("error while reading");

    let provider = Provider::new(Http::new(rpc_url.parse().unwrap()));
    let wallet = pk.parse::<LocalWallet>()?;
    let nonce = provider.get_transaction_count(wallet.address(), None).await?;
    let (maxFeePerGas, maxPriorityFeePerGas) = provider.estimate_eip1559_fees(None).await?;

    // Blob
    let kzg = Kzg::new_from_trusted_setup(trusted_setup).unwrap();
    let blob = Blob::from_bytes(&vec![1; BYTES_PER_BLOB]).unwrap(); 
    let commitment = kzg.blob_to_kzg_commitment(&blob).unwrap();
    let proof = kzg.compute_blob_kzg_proof(&blob, commitment).unwrap();

    let c = Bytes48::from_hex("0xaa1a1c26055a329817a5759d877a2795f9499b97d6056edde0eea39512f24e8bc874b4471f0501127abb1ea0d9f68ac1").unwrap();
    let sidecar = SideCar {
        blobs: vec![[42; BYTES_PER_BLOB]], 
        commitments: vec![c.into_inner()],
        proofs: vec![<KzgProof as Into<[u8; 48]>>::into(proof)],
    };

    let mut tx = TxEip4844 {
        chain_id: 5,
        nonce: nonce.to_string().parse().unwrap(),
        gas_limit: 2_000_000,
        max_fee_per_gas: maxFeePerGas.to_string().parse().unwrap(),
        max_priority_fee_per_gas: maxPriorityFeePerGas.to_string().parse().unwrap(),
        to: address!("40B5d89fCE766a0076Bd55dE77726696527e06B7").into(),
        value: U256::from(0),
        access_list: AccessList(vec![]),
        blob_versioned_hashes: vec![
            FixedBytes::new(commitment.calculate_versioned_hash().to_fixed_bytes())
        ],
        max_fee_per_blob_gas: 65_535,
        input: bytes!(),
    };

    let sc = BlobTransactionSidecar::new(
        vec![FixedBytes::new(sidecar.blobs[0])], 
        vec![FixedBytes::new(sidecar.commitments[0])], 
        vec![FixedBytes::new(sidecar.proofs[0])], 
    );

    //let mut buffer2 = vec![];
    let signature = wallet.sign_transaction_sync(&mut tx)?;
    let tx2 = TxEip4844WithSidecar::from_tx_and_sidecar(tx, sc);
    let variant = TxEip4844Variant::TxEip4844WithSidecar(tx2);
    let signed = variant.into_signed(signature);
    let envelope = TxEnvelope::Eip4844(signed);

    // Send tx
    let result = provider.send_raw_transaction(envelope.encoded_2718().into()).await?;
    println!("{:?}", result);
    Ok(())
}

[mattsse]

ref #239

[DaniPopes]

Is this fixed with #239? @Rjected @prestwich

[Rjected]

Is this fixed with #239? @Rjected @prestwich

it should be, @noahfigueras do you mind trying with latest main?

[noahfigueras]

Hi sorry! for the late reply @Rjected ,just saw this. it's fixed. I have a working example here