Crystality & PREDA | Parallel EVM Runtime

I started writing smart contracts in 2018, and one thing always bothered me: why did running my own RPC mean running a full node, or an archive node if I wanted historical state? My app only cared about my contracts, a few dependencies and some ERC20s. Why did I need to keep up with everything everyone else was doing on Ethereum just to serve those reads? The annoying part was keeping that smaller set of state up to date. Reading a value at one block was doable, but knowing what changed in the next block meant executing it or asking a node that had. A transaction could reach my contract through several other contracts, so just filtering transactions by their destination wasn’t enough. I mostly forgot about it. RPC providers got reliable enough for what I needed, and I had other things to build. I still didn’t love the setup, but it stopped being something I spent time thinking about. Then over the weekend, I was looking through Glamsterdam’s EIPs and realized block-level access lists might make this practical. BALs include the state changes made during a block, including the new values, and the block commits to that list. So once you have the initial state you care about, you can follow its changes without re-executing every transaction. So I started vibe coding it. It’s called skim. You tell it which accounts and storage slots you care about, or let it discover the state your simulations read. It fetches the initial values from Ethereum’s P2P network through SNAP, checks their Merkle proofs, and keeps them updated using BALs. Your eth_calls then run locally. If a call needs something it hasn’t fetched, it gets that from peers too, just with more latency. No upstream RPC provider for those reads. It can also keep historical versions of the state you’re tracking. That was another thing I wanted: being able to query my app’s past state without keeping everyone else’s history. It exposes a JSON-RPC interface, so existing tools can use it for the methods it supports. It still receives full payloads and BALs. The state it maintains is selective, not everything it downloads. There’s also a consensus light-client implementation now, but that path isn’t active on Sepolia yet because the required Gloas light-client data isn’t being served by the peers tested so far. For now, the head is still trusted. It’s still an experiment, and I’m working through correctness bugs and longer-running tests. I’m not presenting it as a production node replacement. But it’s pretty satisfying to finally build something around a complaint I’ve had since 2018. I wanted a small client that knows the parts of Ethereum my app actually uses, and that’s what I’m trying to make. github.com/leekt/skim