CHr15F0x
CHr15F0x
We need proper peer management. Currently if we want to query the network for XYZ we: 1. periodically update a list of peers with XYZ-protocol capability 2. shuffle the list...
Remove the: `#[serde_as(as = "Vec")]`: ```rust= module.register_async_method( "starknet_addInvokeTransaction", |params, context| async move { #[serde_with::serde_as] #[derive(Debug, Deserialize)] struct NamedArgs { function_invocation: ContractCall, #[serde_as(as = "Vec")] signature: Vec, #[serde_as(as = "FeeAsHexStr")] max_fee:...
It's [`pipe_each`](https://github.com/eqlabs/pathfinder/blob/9e0ceec2c56a88ed58b6e49ee7ca6bccd703af33/crates/pathfinder/src/sync/stream.rs#L71) where [the items computed/processed](https://github.com/eqlabs/pathfinder/blob/9e0ceec2c56a88ed58b6e49ee7ca6bccd703af33/crates/pathfinder/src/sync/stream.rs#L89) don't depend on each other so the entire collection mapping could be `rayon`-ized.
Currently both checkpoint and tracking sync do not update class and storage tries. As a result storage and class commitments are stored as `0`s when syncing via p2p.
Add meaningful spans. This should shorten, unify and improve the value of sync logs be it on p2p client level or at the sync logic level.
Observed loop of: ``` 2024-07-22T11:02:28 TRACE Searching for next gap head=0 2024-07-22T11:02:28 TRACE Start of search was missing head=0 2024-07-22T11:02:28 TRACE Found gap head=0 tail=0 2024-07-22T11:02:28 INFO sync_headers: Syncing headers...
Right now `TransactionVariant::try_from_dto` can trigger deployed contract address computation (literally hashing) depending on transaction type in async context. This should deferred as long as possible to (hopefully) after commitment verification.
Consider chunking the backward sync, ie. decrease the initial request from "everything till latest L1" to some lesser value.
Timeout is set on all expected responses from the stream so longer reply streams always time out. Increase the timeout or make it count for the time when no reply...