Empirical Evaluation of Hybrid Ethereum-Ipfs Architectures Under High-Throughput Workloads: Storage Expansion, Memory Utilization, and Access Latency

Abstract

Scalability issues in Ethereum-based blockchain systems can be attributed to bloat in the global state, where every node is required to host a local copy of the account state, smart contracts and their respective storage in the state tries. The idea of using a combination of on-chain and off-chain approaches limits the growth of the global state by storing a portion of the payload in decentralized off-chain stores, such as the InterPlanetary File System (IPFS), and only committing to the ledger an immutable, fixed-size Content Identifier (CID). While the performance and system-level resource trade-offs of this approach have been investigated, it would benefit from quantifying these under real-world conditions with high-throughput, write-heavy loads. The performance characteristics of a hybrid, dual-layer system consisting of a Go-Ethereum (Geth v1.13.14) archive node coupled with an IPFS Kubo (v0.26.0) node and running a Hyperledger Caliper test benchmark workload with a high frequency transaction rate composed of writes, submitted from four concurrent workers with hard resource limits imposed on the Docker containers (1.5 CPUs, 2048 MB RAM), are described. Throughput, network I/O and storage I/O metrics are measured and analyzed using native HTTP RPC latencies and hardware counters. Results show that while limiting the growth of on-chain state using raw data payloads reduces the overall size from 77 MB to 95 MB over the course of the benchmark run. The latency of off-chain IPFS store is 57.1 ms in the worst case (95th percentile; P95) when operating at full saturation for four workers. On the other hand, the average access time for retrieving payloads via IPFS fetch is almost instantaneous (sub-5 ms). Container memory consumption starts out at 3500 MB, which peaks initially before flattening out around 1700-1780 MB (depending on the garbage collector mode of the Go runtime). These results offer definitive upper bounds for using a hybrid decentralized storage approach in edge scenarios with tight resource constraints.