Abstract
Even when blockchain data is encrypted at the application layer, the access pattern itself leaks information. A user querying their account balance reveals which storage slot they care about; repeated queries reveal behavioral patterns that can deanonymize participants even without reading the ciphertext. Oblivious RAM (ORAM) is a cryptographic primitive that hides access patterns by shuffling and re-encrypting memory on each access. Applied to blockchain state queries, ORAM allows clients to retrieve on-chain data from untrusted nodes without revealing which records they accessed. This article surveys the practical ORAM constructions relevant to blockchain contexts and the tradeoffs that govern deployment.
Access Pattern Leakage in Blockchain Nodes
Light clients and dApp frontends typically query full nodes via JSON-RPC calls like eth_getStorageAt or eth_call. These calls are logged by infrastructure providers (Infura, Alchemy, QuickNode) and are visible to network-layer observers. Even over TLS, the full node knows precisely which contract addresses and storage slots were accessed. For financial applications - lending protocols, private DEX orderbooks, confidential token balances - this metadata leaks trading intent, position sizes, and behavioral cadence. The Ethereum privacy ecosystem has largely addressed transaction privacy (via Tornado Cash successors and private mempools) but node-query privacy remains an open problem for deployed applications.
PathORAM and Circuit ORAM
The two ORAM constructions most relevant to blockchain query applications are PathORAM and Circuit ORAM. PathORAM, introduced by Stefanov et al. in 2013, organizes a binary tree of encrypted buckets and routes each access through a random path root-to-leaf, re-randomizing accessed buckets before returning them. Access overhead is O(log N) symmetric-key operations per query, where N is the database size. For Ethereum’s state trie with roughly 300 million storage slots as of mid-2025, this yields approximately 28 tree levels and requires the client to maintain a position map and stash.
Circuit ORAM improves on PathORAM by eliminating the stash and reducing the constant factors in the access overhead, making it more suitable for implementation inside ZK circuits. Projects building verifiable private queries - where the client also wants a proof of correct retrieval - prefer Circuit ORAM because the simpler data-dependent branching reduces circuit depth. The Aztec Network’s private state model uses an ORAM-inspired note commitment tree to ensure that which notes a user reads is not visible to the sequencer.
Practical Deployments and Bandwidth Costs
ORAM is bandwidth-intensive. A single PathORAM access for a 32-byte storage slot against a 2^28-entry database transfers roughly 28 bucket-reads of 64 bytes each, totaling about 1.8 KB per query compared to 32 bytes for a plain query. This 56x overhead is the fundamental cost of hiding access patterns. Compressed ORAM schemes and client-side caching of the position map reduce repeated-access overhead but do not change the asymptotic picture.
The Seal project (from the Applied Crypto Group) and Mysten Labs’ research on “ORAM for light clients” have both explored hybrid approaches where the server holds an oblivious index while the client holds a small local map, reducing per-query bandwidth at the cost of multi-round interaction. These remain research prototypes as of mid-2025, but the Ethereum light client working group has included private queries as a roadmap item for the Portal Network.
When to Use ORAM vs. PIR
Private Information Retrieval (PIR) is an alternative that achieves computational or information-theoretic query privacy with different tradeoffs. Single-server PIR requires heavy homomorphic encryption on the server side; multi-server PIR is practical but requires non-colluding servers. ORAM requires a stateful server (or client) and O(log N) symmetric operations but works with a single untrusted server and no homomorphic computation. For blockchain state queries against a single full node, ORAM is currently more practical than single-server PIR at real state sizes.