Component

rpc-types

Describe the feature you would like

Blocked by #77

trait Network { 
    const __ASSERT_ZST: () = { assert!(std::mem::size_of::<Self>() == 0); };
    type TransactionResponse: RpcObject;
    type TransactionRequest: RpcObject;
    type Receipt: RpcObject;
    type Header: RpcObject;
}

// Modify existing block types in rpc-types/src/eth/block.rs
enum BlockTransactions<N: Network> {
    Hashes(Vec<B256>),
    Full(Vec<N::TransactionResponse>),
    Uncle,
}

struct BlockFor<N: Network> {
    #[serde(flatten)]
    pub     header: N::Header,

    #[serde(skip_serializing_if = "Option::is_none")]
    pub total_difficulty: Option<U256>,

    pub uncles: Vec<B256>,

    #[serde(skip_serializing_if = "BlockTransactions::is_uncle")]
    pub transactions: BlockTransactions<N>,

    pub size: Option<U256>,

    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub withdrawals: Option<Vec<Withdrawal>>,
}

Additional context

No response

Component

signers

Describe the feature you would like

Signature should implement alloy_rlp::Encodable and alloy_rlp::Decodable

Additional context

No response

Component

rpc-types

Describe the feature you would like

cc @Evalir

Additional context

No response

Component

json-rpc

What version of Alloy are you on?

latest

Operating System

macOS (Apple Silicon)

Describe the bug

When serializing a single RequestPacket, only the request part of the SerializedRequest is serialized, and doesn't the include the id or method. This means that an invalid request is created as no id or method is sent. This leads to the error Error response: ErrorPayload { code: -32600, message: "Invalid json-rpc request", data: None }

The fix I found was to add a new Payload struct that contains the id, method and params and serialize that.

Component

consensus, eips, genesis

Describe the feature you would like

Objective

Enhance Alloy to support EIP-712 transactions, enabling account abstraction / deployment for zkSync users that want to make use of alloy for their projects and tooling. In order to do so, alloy would need to support 712-transactions. Example:

pub struct Eip712Transaction {
    pub tx_type: U256,
    pub from: Address,
    pub to: Address,
    pub gas_limit: U256,
    pub gas_per_pubdata_byte_limit: U256,
    pub max_fee_per_gas: U256,
    pub max_priority_fee_per_gas: U256,
    pub paymaster: Address,
    pub nonce: U256,
    pub value: U256,
    pub data: Bytes,
    pub factory_deps: Vec<Bytes>,
    pub paymaster_input: Bytes,
    pub chain_id: U256,
}

Additional context

Resources

There is an initial implementation in zkSync rust-web3-rs sdk of 712-transactions which can be viewed here: 712-tx. It would be great to be able to extend alloy to include this functionality / support.

• rust-web3-rs sdk: https://github.com/lambdaclass/zksync-web3-rs/
• Relevant docs: https://docs.zksync.io/zk-stack/concepts/transaction-lifecycle.html#eip-712-0x71

Component

rpc-types

Describe the feature you would like

having the commonly used helpers separately is useful.

for example

alloy-genesis needs them but doesn't need any of the rpc types itself

Additional context

No response

Component

consensus, eips, genesis

Describe the feature you would like

Some basic types and constants should support no-std

Additional context

No response

Component

rpc-types

What version of Alloy are you on?

latest

Operating System

None

Describe the bug

REVM access lists are U256, while we use FixedBytes<32>. We should use the same ones for both. We may have a mild preference for U256 in the JSON rpc request type because the encoding is significantly shorter for common cases

Component

nodes

Describe the feature you would like

add try_spawn functions for

and

Additional context

No response

Component

consensus, eips, genesis

Describe the feature you would like

Move node-specific code to a node-specific workspace

Additional context

No response

Component

providers

Describe the feature you would like

currently the Provider and RpcClient are not Clone which is a limitation when we want to use a provider in a type that ideally is Cloneable, otherwise we'd need to go back to Arc<Provider>

all of this can be made Clone, we already assume that Transport is Clone for the Provider to work:

Additional context

No response

Component

rpc-types

What version of Alloy are you on?

master

Operating System

macOS (Apple Silicon)

Describe the bug

[Bug] uncles in Block must be with #[serde(default)]

https://github.com/alloy-rs/alloy/blob/main/crates/rpc-types/src/eth/block.rs#L27

Component

consensus, eips, genesis, rpc

Describe the feature you would like

Right now, there's a few types between rpc-types and eips which could be consolidated, such as the AccessList type, although the types in eips do implement different utilities like arbitrary traits, while the types in rpc-types are only concerned with rpc.

If we don't want to unify them, we can provide From impls between them to avoid having to write conversion functions whenever we use both.

Additional context

No response

Component

signers

What version of Alloy are you on?

No response

Operating System

None

Describe the bug

Signers::sign_transaction and SignerSync::sign_transaction_sync should not apply EIP-155 when the signer's chain_id is None. Indeed, this is the expected behavior according to Signer's docstring, but EIP-155 is applied anyway if the chain ID is found on the transaction instead.

Ref:

EIP-{1559,2718} always embed a chain ID value but they're not compatible with EIP-155. Thus, they get an EIP-155 signature when they shouldn't.

Component

providers, pubsub

Describe the feature you would like

This issue has been requested to be opened, in relation to twin issue in ethers-rs gakonst/ethers-rs#2729

The intention here is to support methods for subscription other than eth_subscribe, which in the ethers-rs case is hard-coded into this functionality

Additional context

No response

Component

signers

What version of Alloy are you on?

d024781

Operating System

Linux

Describe the bug

During testing for #161 I encountered a legacy transaction that failed signing with: Code 6a80 APDU_CODE_BAD_KEY_HANDLE

It seems that this only happens with specific calldata that might be known to the device.

This is the transaction:

Ported from an ethers-rs test, which also failed with the same error.

Component

json-rpc

What version of Alloy are you on?

v0.1.0 (latest main branch)

Operating System

Linux

Describe the bug

Looking at:

It seems PubSubItem try to deserialize an EthNotification from a json that looks like this:

{
  "jsonrpc": "2.0",
  "method": "eth_subscription",
  "subscription": "0x..."
  "result": {},
}

Whereas the correct json is like this:

{
  "jsonrpc": "2.0",
  "method": "eth_subscription",
  "params": {
    "subscription": "0x..."
    "result": {},
  }
}

Component

network, json-rpc, rpc, transports

Describe the feature you would like

If I understood everything correctly, the current types are

pub enum ResponsePacket<Payload = Box<RawValue>, ErrData = Box<RawValue>> {
    Single(Response<Payload, ErrData>),
    Batch(Vec<Response<Payload, ErrData>>),
}

The overall tower::Service Error type is

type Error = alloy_transport::TransportError;

In a single call type, if there's a transport error or serialization error, it can return an error for tower::Service. Though, for a single failure in a batch call, the responses can only return RPC errors. If a single RPC call in the batch needs to return a serialization or transport related error, it must fail all of the other calls in the batch.

I tried to fix this issue in the transport I was writing by using transport and serialization errors as RPC errors, which isn't consistent with how provider errors are supposed to be interpreted.

Additional context

No response

Component

rpc-types

Describe the feature you would like

cc @Evalir

Additional context

Component

providers, rpc-types

Describe the feature you would like

implement the network trait from #80 for an AnyNetwork which contains the standard ethereum JSON-RPC types + an extra_fields: HashMap<String, Value>. If necessary, differentiate AnyTransaction from the transaction types described in #73

Additional context

No response

Component

signers

Describe the feature you would like

There is no need to pass B256 by value since we're always using it as a slice &[u8]. This was introduced in #83

• See alloy-rs/core#487

Additional context

No response

Component

json-rpc

What version of Alloy are you on?

latest

Operating System

macOS (Apple Silicon)

Describe the bug

When issuing single-parameter json-rpc requests to endpoints like eth_getBalance, it seems they are not serialized correctly to still send an array of params in JSON, failing with the following error: ErrorPayload { code: -32600, message: "Invalid json-rpc request", data: None }

The workaround is to make Params be a Vec<_>, but this should not be necessary.

if not how should i serialize my transaction to be be signed. Working on something like thi

       let mut payload = Self::path_to_bytes(&self.derivation);

        // need to figure out how to encode the alloy TypedTransactionRequest into a Vec<u8>
        payload.extend_from_slice(tx.encode().as_slice());

        let mut signature = self.sign_payload(Instruction::Sign, &payload).await?;

Component

rpc-types

What version of Alloy are you on?

No response

Operating System

None

Describe the bug

#66 was expedited to unblock the providers migration on foundry. However, this introduces a catch-all that we'd rather not have. Once foundry-rs/foundry#6219 is merged we should remove this catch-all field and instead use a wrapper type WithExtraFields<T> that can hold arbitrary values on the map, and the original type too.

Component

providers

Describe the feature you would like

move cli bindings for clients from ethers-core to alloy

perhaps into a new crate?

Additional context

No response

Component

pubsub

What version of Alloy are you on?

v0.1.0 (commit 50e38e8)

Operating System

Linux

Describe the bug

I'm using pubsub to subscribe to neHeads and logs via my Alchemy provider, and a get this error a few times a day:

ERROR WS connection error while receiving a response err=WebSocket protocol error: Connection reset without closing handshake

immediately followed by these logs:

 INFO Reconnecting pubsub service backend.
DEBUG Draining old backend to_handle
DEBUG Reissuing pending requests count=0
DEBUG Re-starting active subscriptions count=2

And that's it, I don't receive notifications anymore after that.

After adding more traces I noticed that new subscriptions are sent to the server, but the responses are not handled, because the reconnect logic doesn't add back in-flight request, and it's needed:

Another issue: Looking at PubSubService::reconnect(), I noticed that all server ids are dropped, leading to close the connection between the backend and the frontend.

Component

providers

Describe the feature you would like

builder style Request types (Optional fields) that have a corresponding Transaction type (valid Transaction).

yes, love this plan :)

going from Request -> Transaction is what we called fill in ethers.

This is a little more complex, I think. The TransactionRequest generally allows a from field, which the Transaction that implements RLP should not

So we may want something like:

• Transaction - complete, no from field, implements RLP, no serde
• SignedTransaction - complete, no from field, contains Transaction + Signature, no serde
• TransactionRequest - builder for the JSON request object
• Provider::fill(&mut TransactionRequest)
  • populates all possible fields from RPC node
  • should ensure that TransactionRequest::try_into_transaction definitely succeeds
• Signer::sign_transaction(&TransactionRequest) -> Result<SignedTransaction>
  • errors when the request is missing info, or if from is populated with address signer can't sign from
• TransactionResponse - JSON object returned by eth_getTransactionByXXXX methods
  • should ALWAYS contain a SignedTransaction

Originally posted by @prestwich in #44 (comment)

Additional context

No response

Component

consensus

What version of Alloy are you on?

latest

Operating System

macOS (Apple Silicon)

Describe the bug

Decoding a legacy transaction from its raw RLP seems to not work.

Using https://etherscan.io/tx/0x280cde7cdefe4b188750e76c888f13bd05ce9a4d7767730feefe8a0e50ca6fc4 as an example, we can access the raw RLP in Etherscan: https://etherscan.io/getRawTx?tx=0x280cde7cdefe4b188750e76c888f13bd05ce9a4d7767730feefe8a0e50ca6fc4 . As we can see, the expected signer is 0xa12e1462d0ced572f396f58b6e2d03894cd7c8a4. Although, when running a test to recover the signer using alloy, it gives 0x133e78b108f8ffb7b1e07790d60e2babbcc9b3d8, which is not the expected signer.

Test vector:

    #[test]
    #[cfg(feature = "k256")]
    fn decode_legacy_and_recover_signer() {
        use crate::TxLegacy;
        use alloy_network::Signed;
        use alloy_primitives::address;

        let raw_tx = "f9015482078b8505d21dba0083022ef1947a250d5630b4cf539739df2c5dacb4c659f2488d880c46549a521b13d8b8e47ff36ab50000000000000000000000000000000000000000000066ab5a608bd00a23f2fe000000000000000000000000000000000000000000000000000000000000008000000000000000000000000048c04ed5691981c42154c6167398f95e8f38a7ff00000000000000000000000000000000000000000000000000000000632ceac70000000000000000000000000000000000000000000000000000000000000002000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc20000000000000000000000006c6ee5e31d828de241282b9606c8e98ea48526e225a0c9077369501641a92ef7399ff81c21639ed4fd8fc69cb793cfa1dbfab342e10aa0615facb2f1bcf3274a354cfe384a38d0cc008a11c2dd23a69111bc6930ba27a8";

        let tx = <Signed<TxLegacy> as Decodable>::decode(&mut alloy_primitives::hex::decode(raw_tx).unwrap().as_slice()).unwrap();
        let recovered = tx.recover_signer().unwrap();
        let expected = address!("a12e1462d0ceD572f396F58B6E2D03894cD7C8a4");
        assert_eq!(expected, recovered, "Expected same signer");
    }

Test vector obtained from gakonst/ethers-rs#1732 — both issues seem to be very similar.

I want to recommend that this repository use release-plz for automatic semantic versioning and releases. When done manually this is error prone and can cause trouble for down stream dependancies. As the rust ethereum ecosystem starts to stabilize i think this is a good idea that preemptively reduces probability of incorrectly incremented semver, and upstream breaking changes. Release please will detect diffs between main and the last release tag, auto detect and increment semantic versioning in a PR and open that PR with a release tag, new semver, and a change log of the commit history. If you like i can open a PR that is an example of configuring this, however, it's important to note that the owner of the project must configure the github secret and if you want to auto publish to crates.io also the api key for crates. I think this is an important step towards more stability for the rust ethereum ecosystem.

Component

rpc-types

Describe the feature you would like

TODO

replace the genesis types defined in node-bindings crate with the new ones in alloy-genesis

Additional context

No response

Component

providers

Describe the feature you would like

We should be able to support WASM for at least the Signer/SignerSync traits and Ledger signer. For the former, only rand/getrand is blocking

Additional context

No response

Component

json-rpc, rpc-client

Describe the feature you would like

Implementation of eip-3668, the cross chain interoperability protocol.

CCIP is already natively integrated in most other ethereum libraries, enabled by default, and powers a core part of the ENS protocol.

Specification:
https://eips.ethereum.org/EIPS/eip-3668

PS: Please adjust the component this issue is tagged for if needed.

Additional context

• ethers-js
• viem
• ethers-rs-middleware

Component

providers, pubsub

Describe the feature you would like

The buffer size for subscriptions is currently a constant.

This should be configurable.

we should add settings for the

so you can call connect(connector, settings)

wdyt @prestwich

Additional context

No response

Component

No response

Describe the feature you would like

Foundry has some special handling for some L2s (e.g. Arbitrum), and we use a catch all/fallback field in the block header to look up extra properties on these L2s. This is both used in the forking backend (here) and in Cast (to show all fields in e.g. cast block)

Additional context

No response

Component

providers, rpc-client

Describe the feature you would like

A task that subscribes to block headers, and allows watching blocks for confirmed transactions, and notifying subscribers

Task should

• contains a subscription to block headers
• contain a tx_hash_receiver: tokio::sync::mpsc::Receiver<(B256, broadcast::Sender<()>)>
• contain a tx_senders: HashMap<B256, tokio::sync::broadcast::Sender<()>>
• retrieve each block as the header notification occurs
• detect missing block header notifications and retrieve those blocks as well
• iterate over all txn hashes in the block
• dispatch a notification to the appropriate channel, if necessary.

maybe feature

• store txns and rebroadcast them every N seconds?

Pending Transaction

• contains an RpcClient ref
• thin wrapper around tokio::sync::broadcast::Receiver
• on receipt of notification, retrieves the receipt via eth_getTransactionReceipt
• impl Future { type Output = RpcResult<Receipt>; }

Modify RpcClient

• hold a tokio::sync::mpsc called tx_hash_sender which communicates tx hashes to watch for to the co-routine

Provider method

• modify send_transaction and send_raw_transaction to send hashes via the tx_hash_sender AFTER broadcast

Additional context

Component

providers

Describe the feature you would like

in the crate dir, under rpc-client/call.rs for error handling the code currently uses unreachable! when it encounters an incorrect state. won't it be better to use custom errors Instead of using unreachable! or maybe i'm missing something

Additional context

No response

Component

transports

Describe the feature you would like

Remove the + Send from the Transport Service dyn futures, and the Conn::Future: Send bound from impls when #[cfg(target_arch = "wasm32")]

Additional context

Turn WASM CI back on

Component

new component

Describe the feature you would like

contains primitive txn and receipt types, and transaction traits as described in #73 and #77

add to CI components list

Additional context

No response

Component

No response

What version of Alloy are you on?

No response

Operating System

None

Describe the bug

Document stuff.

Component

network, json-rpc, rpc

What version of Alloy are you on?

https://github.com/alloy-rs/alloy#e104f7df

Operating System

macOS (Apple Silicon)

Describe the bug

Expected behavior: Client subscribes and receives blocks.

Actual behavior: Client never receives blocks.

use alloy_rpc_client::{ClientBuilder, RpcClient, WsConnect};
use alloy_rpc_types::pubsub::{SubscriptionKind};
use alloy_pubsub::PubSubFrontend;

#[derive(Debug)]
struct Listener<PubSubFrontend> {
    rpc_client: RpcClient<PubSubFrontend>,
}

impl Listener<PubSubFrontend>
{
    fn new(rpc_client: RpcClient<PubSubFrontend>) -> Self {
        Self { rpc_client }
    }

    async fn run(&self) -> anyhow::Result<()> {
        println!("Subscribing to new block headers");
        // Prepare the request
        let subscribe_request = self.rpc_client.prepare("eth_subscribe",  [serde_json::to_value(SubscriptionKind::NewHeads)?]);

        // Make the request with a 2 second timeout
        let timeout = tokio::time::timeout(std::time::Duration::from_secs(2), subscribe_request);

        // Unwrap the response
        let subscriber_id =  timeout.await.unwrap().unwrap();
        println!("Subscribed to new block headers with subscriber id: {:?}", subscriber_id);

        let mut block_rx = self.rpc_client.get_watcher(subscriber_id).await;

        println!("Receiving new block heads");

        loop {
            // This should loop forever getting new block heads
            let block_head = block_rx.recv().await.unwrap();
            println!("Got new block head");
        }
    }


}

#[tokio::main]
async fn main() -> anyhow::Result<()> {
        println!("Starting block listener");
        // Get a websocket connector
        let connector = WsConnect { url: "ws://redacted.to_string(), auth: None };
        let client = ClientBuilder::default().pubsub(connector).await.unwrap();
        // Start the block listener
        let listener = Listener::new(client);
        listener.run().await
}

Component

providers

Describe the feature you would like

https://github.com/georgewhewell/ethers-gcp-kms-signer

Additional context

#44 (review)

Component

providers

What version of Alloy are you on?

0.1.0

Operating System

Linux

Describe the bug

The type for block numbers is inconsistent across the API

For example:

• BlockNumberOrTag::Number(u64) in RPC types
• Provider::get_block_number gives a U256
• number in Header in RPC types is Option<U256>
• The BlockNumber type alias in Alloy primitives is u64

I'm unsure if this is by design or not, but it makes the API a bit cumbersome to work with at times

Component

new component

Describe the feature you would like

Transaction traits that provide common getters/setters for transactions. Should be implemented on primitive tx types as described in #73.

trait Transaction { value, data, etc  }
trait LegacyTransaction: Transaction { fn get/set_gas_price() }
trait TransactionEip1559: Transaction  { fn get/set_max_priority_fee_per_gas() }
trait TransactionEip2930: LegacyTransaction { fn get/set_access_list() }

Additional context

No response

Component

providers, pubsub, transports

Describe the feature you would like

We should explain that the transports are tower services and how to layer things like retries/backoff (with a simple example) in either the provider or transport docs (or both).

Additional context

No response

Component

consensus, eips, genesis

What version of Alloy are you on?

https://github.com/alloy-rs/alloy#42778ba4

Operating System

macOS (Apple Silicon)

Describe the bug

    let raw_tx = hex::decode("02f86f0102843b9aca0085029e7822d68298f094d9e1459a7a482635700cbc20bbaf52d495ab9c9680841b55ba3ac080a0c199674fcb29f353693dd779c017823b954b3c69dffa3cd6b2a6ff7888798039a028ca912de909e7e6cdef9cdcaf24c54dd8c1032946dfa1d85c206b32a9064fe8").unwrap();
    let res = alloy_consensus::TxEnvelope::decode(&mut raw_tx.as_slice());

Returns alloy_rlp::Error::UnexpectedLength. Seems it's expecting a non-empty buffer here:

Component

providers, pubsub

Describe the feature you would like

Remove async from PubSubFrontend::unsubscribe since it's not really async.
It's stopping me from being able to implement a RAII object that unsubscribes on drop.

Additional context

No response

Component

network, json-rpc

Describe the feature you would like

The reason I need this right now is to be able to subscribe to newPendingTransactions and generate a rlp encoded txs from the tx stream.

Additional context

No response

Component

consensus, eips, genesis

Describe the feature you would like

Add both EIP4844 variants to

https://github.com/alloy-rs/alloy/tree/main/crates/consensus/src/transaction

https://github.com/paradigmxyz/reth/blob/add3c6a3a2ae0cecd8627533bbc5688a456435ad/crates/primitives/src/transaction/eip4844.rs

https://github.com/paradigmxyz/reth/blob/add3c6a3a2ae0cecd8627533bbc5688a456435ad/crates/primitives/src/transaction/sidecar.rs#L48-L58

with and without sidecar

Additional context

No response

Component

signers

Describe the feature you would like

It'd be nice to have direct conversions from B256 to LocalWallet.

Additional context

No response