Network layer validator privacy is vital to strengthen Ethereum's robustness and censorship resistance.
Attestations are the strongest deanonymization signal: they're recurring, deterministic, and correlatable. But they're also time-sensitive, requiring strict latency and deliverability guarantees to ensure chain stability.
The direction I'm exploring for attestation propagation (as a native networking layer feature):
→ OHTTP-like two-hop shuffle (breaks IP-to-attestation link) while bounding delivery time (targeting 300ms p90)
→ Prioritized validator meshes via a ZK "proof of validator" (sybil-resistant without revealing identity)
→ Rate limiting nullifiers (prevents spam/garbage flooding)
→ Decoy traffic injection (obfuscates behavioural patterns)
In just 5 days, you will be able to deploy Smart Contracts on the @Filecoin Virtual Machine (FVM) on mainnet.
Today I wanted to dig into the FVM’s EVM compatibility (affectionately termed 'FEVM') 🧵
The FVM is a Wasm-based blockchain execution environment designed to host multiple runtimes. It’s inspired by the concepts of VM hypervisors and OS virtualization. It can run code written for EVM (today), SES, eBPF, or other blockchain runtimes (future).
It rests on a number tech choices made throughout Filecoin’s history to keep the protocol modular, future-proof and extensible, e.g. multi-addressing, IPLD.