List view
The goal of this milestone is for Pathfinder to be able to participate in Starknet consensus as a validator.
Due by December 31, 2025•2/19 issues closed- No due date•2/2 issues closed
- No due date•23/25 issues closed
- No due date•2/2 issues closed
- No due date•15/15 issues closed
- No due date•38/38 issues closed
- No due date•4/7 issues closed
Storage has its own `BlockId` which excludes the `Pending` variant. This is because storage has no concept of pending data since it is stored ephemerally in memory. Historically, pending data was completely disconnected from the data on disk but this led to consistency issues as it is difficult to synchronize memory and database transactions. This was solved by requiring a database transaction to unlock the pending data - it is only unlocked if the pending data is valid in the context of the latest block on disk for the given transaction. Pending data currently lives in RPC as this is the only place in which it is used. The downside of this has been that pending queries always have a different logic path in each RPC method, and that RPC block ID needs special casing to become the storage's block ID. We can solve this by moving ownership of `PendingData` from RPC to the Storage crate. This lets us use the common `BlockId` type every as storage can now handle `BlockId::Pending` queries.
No due date•3/3 issues closedProvide proofs for a transaction and its events via a pair of pathfinder RPC extension methods. We already have the proof generation code for storage proofs, so this would just be a slightly different application thereof. I suggest separating the transaction and event proofs into two methods to keep each code piece simpler.
No due date•0/4 issues closedA new sync process designed specifically for P2P.
No due date•40/44 issues closedFeatures, refactoring and improvements to the codebase that provide useful utilities and reduce papercuts.
No due date•3/4 issues closedConstant churn induced by frequent RPC version updates is one of our biggest sources of bugs. Better tooling and testing would help us alleviate this problem. One obvious solution is to use codegen but this has several undesirable outcomes 1. The generated code is horrible and complex as the spec is heavily nested (and also contains bugs) 2. We want to re-use code from different RPC versions but without duplicating all of it just to cater for minor spec differences 3. We want more performance by not copying excessively. Ideally the serde would be done by thin wrappers around the storage or core types instead of copying to an RPC specific type. Starknet-rs uses (1) after flattening the spec and also doing some fixes by hand but it has the advantage of not really having intermediete types to worry about, and also only supports one RPC version at a time. The broader scope of this work is to help us test our RPC code against the spec, and make it easier to implement changes.
No due date•1/4 issues closed