PaperlayerView exact revision on arXiv

Source-linked AI summary

ChainSEED: A Scalable, High-Fidelity Blockchain Emulator

Qishu Jin, Wenliang Du, Kairui Feng

arXiv:2610.31188v1cs.NI

TL;DR

Blockchain experiments need controlled conditions and integrated ways to interact with systems and observe behavior. ChainSEED combines configurable real-client services with network, workload, and monitoring tools; it supports large Ethereum deployments as well as Monero and Solana emulations and research case studies.

  • Problem

    Blockchain studies need experimental conditions that researchers can configure, interact with, and observe.

    Source: §1 · pp. 1–2

  • Method

    ChainSEED organizes real blockchain clients as configurable services on SEED’s emulated network, with customization, workload generation, application interaction, and monitoring tools.

    Source: §1 · p. 2

  • Results

    400 beacon nodes, 400 execution nodes, and 60,000 validator identities run on one server while sustaining approximately 20 TPS; ChainSEED also emulates Monero and Solana networks and supports research case studies.

    Source: §1 · p. 2

  • Takeaways & Limitations

    ChainSEED connects changes in software, peer relationships, and workloads to observed transaction processing and consensus behavior in controlled experiments.

    Source: §8 · p. 15

Abstract

from arXiv · show

Researchers need blockchain experimental environments with configurable workloads, controllable network conditions, and observable outcomes. Public blockchains and testnets limit experimental control, model-based simulators omit real client implementations, and real-client environments face challenges in combining network control with resource-efficient deployment. We present ChainSEED, a scalable, high-fidelity blockchain emulator built on the SEED Internet Emulator. It separates blockchain configuration from client placement on a configurable routed network. For Ethereum PoS, it organizes separately configured execution, consensus, and validator clients and provides APIs for customizing genesis state, peer connections, and client software. A transaction generator informed by Ethereum mainnet activity, application interfaces, and chain- and node-level monitoring support experiments. ChainSEED also supports Monero and Solana. We examine beacon-node memory reduction, execution-client memory allocation, and validator-client multiplexing to support larger experiments within limited hardware budgets. On a single server with approximately 1 TiB of memory and 384 logical CPU cores, ChainSEED deploys 400 beacon nodes, 400 execution nodes, and 60,000 validator identities while sustaining approximately 20 TPS. It also emulates a 1,200-node Monero network with up to 200 active single-threaded PoW miners and a 200-node Solana network with sustained finalization. Case studies demonstrate routing attacks, blockchain amplification attacks, Monero eclipse attacks, topology-discovery benchmarking against known peer graphs, and network-configuration experiments.

1 Introduction

Blockchain experiments need controlled conditions and observable outcomes, but shared environments limit control and existing platforms face challenges in workload, interaction, and scale. ChainSEED combines configurable real-client services and experimental tools, supporting large deployments and diverse case studies.

1 Introduction

  • Blockchain experiments benefit from conditions that researchers can configure, observe, and repeat to evaluate mechanisms or investigate existing systems.The motivating studies include testing intended benefits and trade-offs, reproducing phenomena, and examining suspected vulnerabilities and defenses.Source: §1 · p. 1
  • Public blockchains and testnets limit researchers’ control over participants and background activity, while isolated deployments allow conditions to vary without disrupting other users.Controlled participation and interactions matter for comparing network conditions and studying failures, attacks, and defenses.Source: §1 · pp. 1–2
  • Researchers need configurable network conditions and representative workloads, integrated interaction and observation, and scalability within limited memory and CPU budgets.The platform must preserve characteristics relevant to the investigation while supporting timely transaction processing and continued consensus progress.Source: §1 · p. 2
  • ChainSEED organizes real blockchain clients as configurable services on SEED’s emulated network, with APIs for customization, workload generation, application interaction, and monitoring.It supports Ethereum, Monero, and Solana.Source: §1 · p. 2
  • 400 beacon nodes, 400 execution nodes, and 60,000 validator identities run on one server while sustaining approximately 20 TPS; ChainSEED also emulates Monero and Solana networks.The same server has approximately 1 TiB of memory and 384 logical CPU cores; the Monero network has 1,200 nodes with up to 200 active single-threaded PoW miners, and the Solana network has 200 nodes with sustained finalization.Source: §1 · p. 2
  • Case studies use ChainSEED for security studies, topology-discovery benchmarking against known peer graphs, and network-configuration experiments.The passage identifies these as examples of the platform’s research utility.Source: §1 · p. 2

2 Background and Related Work

The background describes how Ethereum PoS clients cooperate, how SEED composes and deploys network services, and how blockchain emulators differ in client fidelity, routing control, and deployment costs.

2.1 Ethereum PoS Blockchain

  • Execution clients process transactions and maintain state, beacon clients handle consensus and finality, and validators propose blocks and attest through beacon nodes.The roles cooperate using shared genesis and protocol settings, peer connections, execution payloads, proposals, and attestations.Source: §2.1 · p. 2

2.2 The SEED Internet Emulator

  • SEED separates network construction, routing configuration, and service deployment, then binds logical service nodes to hosts and compiles the composed environment for deployment.Its layers define ASes, hosts, routers, and connections; rendering resolves bindings and integrates configurations before compilation generates deployment files.Source: §2.2 · pp. 2–3

2.3 Comparison with Related Work

  • Blockchain emulators should run real client software because implementations determine how nodes process workloads, synchronize state, and respond to attacks.The cited model-based platforms and Ganache do not expose behavior from a distributed network of production execution and consensus clients.Source: §2.3 · p. 3
  • Controllable routing infrastructure matters because routing policies, link failures, and recovery affect paths and reachability, while delays alone do not capture routing decisions.The passage contrasts ChainSEED’s SEED infrastructure with related deployments that do not incorporate inter-AS routing protocols.Source: §2.3 · p. 3
  • Container-based deployment and reusable services address per-node overhead and extensibility trade-offs that arise when enlarging experiments or changing blockchain architectures.The comparison notes VM overhead in Proteus, topology-coupled startup in Containerchain, and ChainSEED’s client optimizations alongside OS-level resource considerations.Source: §2.3 · p. 3

3 System Design

ChainSEED separates blockchain services from SEED network construction, then binds and deploys them together. Its Ethereum service organizes configurable client roles, while reusable tools support multiple chains, customization, workloads, and observation.

3.1.1 High-level System Architecture

  • ChainSEED constructs blockchain services independently from SEED’s underlying network and late-binds logical blockchain nodes to network hosts, making the service portable.Changing bindings can move a blockchain to another part of the network.Source: §3.1.1 · p. 4, Figure 3 · p. 4
  • Rendering uses bound-host information to complete blockchain configuration, and compilation generates Docker or Kubernetes deployment files for runtime interaction and observation.Users can interact through existing applications and observe chain and node behavior with visualization and monitoring tools.Source: §3.1.1 · p. 4, Figure 2 · p. 4

3.1.2 Ethereum Service Architecture

  • The Ethereum service separates chain-wide configuration from participant-specific roles, endpoints, and client options, coordinating shared state while preserving independent deployment and resource settings.Execution, beacon, and validator participants are associated through virtual-node names and initialized with shared genesis states and startup dependencies.Source: §3.1.2 · pp. 4–5, Figure 4 · p. 5

3.1.3 Extending the Service Design

  • Monero and Solana services adapt client configuration and initialization to their protocols while reusing SEED bindings and compilation, and can share a network with Ethereum clients.The authors implemented both services within two weeks.Source: §3.1.3 · p. 5

3.2 Customization

  • Users can customize execution and consensus genesis, including chain ID, gas limit, account balances, and initial validators, as well as peer connections and client software.Peer choices include bootstrap nodes, peer limits, and selected P2P connections; users can adjust software options or supply modified binaries.Source: §3.2.1 · p. 5, §3.2.2 · p. 6

3.3.1 Monitoring System

  • ChainSEED’s monitoring includes EthExplorer for blockchain data and Ethereum Lookingglass for peer connections, client dependencies, resource use, queues, transaction pools, and event replay.EthExplorer is based on the open-source beaconcha.in explorer.Source: §3.3.1 · p. 6, §3.3 · p. 6

3.3.2 Transaction Generation

  • The transaction generator submits transfers, contract calls, and deployments through client RPCs, using default sampling weights derived from successful Ethereum mainnet transactions.Users can independently adjust transaction mix and submission rate; Sections 4 and 5 use the default mixture.Source: §3.3.2 · p. 6

3.3.3 Integration with Existing Software

  • Standard client interfaces let users connect MetaMask, Remix, and Hardhat for account queries, transaction submission, contract deployment, interaction, and scripted testing.The workflows support interactive application use and automated deployment and testing within the emulated environment.Source: §3.3.3 · p. 6

4 Scalability Analysis and Optimization

Section 4 investigates how to reduce resource costs across beacon, execution, and validator clients while preserving chain operation. Its experiments identify memory and CPU trade-offs in worker caps, execution-client memory limits, and validator multiplexing.

4.1 Reducing Beacon Node Memory

  • Restricting historical-state reconstruction to observer nodes reduces mean beacon-node memory by 12.0%, while reducing the worker cap to two lowers mean memory by 41.5% and P95 memory by 54.6%.The worker-cap reduction yields 0.48 GiB mean and 0.54 GiB P95 memory per node; the default concurrency reflects all 192 logical CPUs visible to each container.Source: §4.1 · p. 7
  • At cap=2, mean high-priority API queue length rises from 1.302 to 1.409 tasks as load increases, then falls to 1.252 when load returns to 15 TPS.Cap=4 follows the same pattern with shorter queues, while mean queue lengths at caps 8 and 16 remain close to zero.Source: §4.1 · pp. 7–8, Table 2 · p. 8
  • At cap=2, beacon nodes use 0.494 GiB on average versus 0.660 GiB at cap=16, while maximum chain-head gaps remain within two slots across tested caps of two or higher.Cap=1 saves only another 0.02 GiB per node but reaches a 43-slot maximum gap; under the tested higher-load workload, cap=2 continues finalization and includes all submitted transactions.Source: §4.1 · pp. 7–8, Figure 5 · p. 8

4.2 Improving Execution-Client Transaction Throughput

  • The 384 MiB execution-client limit uses 0.088 GiB more mean memory per node than 256 MiB, while improving confirmation P95 and reducing missed blocks; 512 MiB eliminates missed blocks in this run.Confirmation P95 at 512 MiB remains close to the 384 MiB result, with additional memory use.Source: §4.2 · pp. 8–9, Table 4 · p. 9
  • At 384 MiB, execution clients reach 24.998 TPS at a 25 TPS load, include all load-phase transactions, and achieve 17.096 s confirmation P95.At 15 TPS, moving from 256 to 384 MiB lowers confirmation P95 from 29.732 to 16.409 s and missed-block rate from 2.583% to 0.042%, with only 0.088 GiB more mean memory per node.Source: §4.2 · p. 9, Table 4 · p. 9, Table 5 · p. 9

4.3 Multiplexing Validators

  • Multiplexing 900 validator identities from 900 clients into 9 reduces mean memory from 39.201 to 0.571 GiB and CPU from 14.639 to 0.359 cores, while all identities remain active and finalization continues.P95 attestation inclusion delay remains one slot, and all 18,000 submitted transactions are eventually included in every configuration.Source: §4.3 · p. 10, Figure 6 · p. 10
  • Consolidating validators reduces duplicated client overhead, but validators managed by one client share its failure fate and may all be unable to perform duties if it fails.The authors recommend balancing resource savings against how many validators a single client failure could affect.Source: §4.3 · p. 10

5 Evaluation

The evaluation tests whether ChainSEED can scale real blockchain clients while maintaining transaction processing and consensus progress. It reports large Ethereum deployments on one server and scalability results for Monero and Solana.

5.1 Scalability: Large-Scale Deployment on a Single Server

  • 400 beacon nodes, 400 execution nodes, and 60,000 validator identities sustain a 20 TPS input on the tested server, with transactions completing and finalized epochs advancing.Across deployment sizes, finalized epochs advance by 47 during each five-hour observation window; at the largest scale, mean validator activity is 99.1% and the missed-slot rate is 0.2%.Source: §5.1 · p. 11, Table 7 · p. 12

5.2 Scalability Beyond Ethereum

  • The 1,200-node Monero network with 200 active single-threaded miners advances 324 blocks in five hours and includes all 5,398 submitted transfers.Across the four miner configurations, all submitted transfers are eventually included; mean CPU use rises from 8.858 to 186.812 logical cores, while mean memory rises from 87.829 to 100.372 GiB.Source: §5.2 · pp. 11–12, Table 8 · p. 12

5.1 Scalability: Large-Scale Deployment on a Single Server

  • 738.4 GiB is the mean container memory at 400 beacon–execution pairs, whose peak usage reaches 844.7 GiB.Across deployments of 100, 200, 300, and 400 pairs, mean memory is 141.9, 313.7, 493.1, and 738.4 GiB; mean CPU use is 155.7, 172.8, 164.8, and 189.4 logical cores.Source: §5.1 · p. 11, Figure 7 · p. 12

5.2 Scalability Beyond Ethereum

  • The 200-node Solana deployment advances its finalized slot number by 3,573 during five hours.Mean container memory is 605.77 GiB and mean CPU use is 178.08 logical cores, including network infrastructure.Source: §5.2 · p. 12

6 Applications

ChainSEED combines real blockchain clients with a configurable network environment for security studies, topology-discovery benchmarking, and network-configuration experiments. The applications illustrate controlled routing and client changes, known peer graphs, and measurable communication trade-offs.

6.1 Security Studies

  • A routing hijack made an Ethereum validator miss its scheduled proposal by blocking access to its beacon node; withdrawing the announcement restored connectivity [10].In a separate client-level study, modified Geth admitted invalid transactions that displaced honest transactions from its pool but were excluded from constructed blocks [46].Source: §6.1 · p. 13
  • Nodes that do not accept inbound Monero connections could still be eclipsed, leaving their access to blockchain information under adversarial control [40].The experiment used 1,200 nodes across 100 autonomous systems.Source: §6.1 · p. 13

6.2 Benchmarking Topology Discovery

  • TopoShot’s inferred links match reference graphs in every tested case up to 32 nodes; on the 100-node path, it identifies 61 of 99 edges with precision 1.0 and recall 0.616.The known peer graphs provide a reference for distinguishing missed links from genuinely absent connections.Source: §6.2 · p. 13, Table 9 · p. 13

6.3 Network Protocol Configuration Studies

  • Reducing Lighthouse’s target peer count from eight to five lowers measured traffic by 19.04%, while mean beacon-head observation spread stays close to 0.94 seconds.The comparison holds the underlying topology and other settings unchanged.Source: §6.3 · p. 14, Table 10 · p. 14

7 Discussion and Future Work

The discussion frames emulator scale as a resource-allocation choice tied to the behaviors an experiment must preserve. Future work extends ChainSEED to additional layered, client, and validator configurations.

7.1 Discussion

  • Beacon concurrency, execution-client memory, and validator multiplexing involve different resource trade-offs, so deployment scale should be assessed alongside synchronization, transaction completion, and consensus progress.The discussion describes lower beacon concurrency as saving memory but potentially increasing queueing, while a larger execution-client memory budget can improve transaction processing.Source: §7.1 · p. 14
  • Validator multiplexing should match the experiment’s failure scope: a shared validator-client failure affects every identity it manages.Independent consensus-node participants and peer connections remain necessary when studying communication among those nodes.Source: §7.1 · p. 14

7.2 Future Work

  • Future Layer-2 experiments will vary workloads and network conditions across rollups and Layer 1 to examine sequencer availability, Layer-1 congestion, throughput, and settlement latency.The proposed experiments also measure the resources needed to host both layers.Source: §7.2 · p. 14
  • Planned Monero and Solana studies will evaluate client resource use alongside transaction completion and chain progress under varied configurations and workloads.For Monero, the plans separate active miners from non-mining nodes; for Solana, they examine transaction-processing and finalization costs.Source: §7.2 · pp. 14–15
  • Planned validator-consolidation support will let researchers vary identity count and client grouping while holding total effective stake fixed.The proposed comparisons examine resource use, duty execution, consensus progress, and the effective stake affected by client failure.Source: §7.2 · p. 15
  • Future client-diversity work will compare execution and consensus implementations under matched network conditions, protocol settings, and transaction workloads.The comparisons will assess whether optimization findings transfer across implementations and compare resource costs at similar throughput and consensus performance.Source: §7.2 · p. 15

8 Conclusion

ChainSEED provides a configurable experimental platform built from real blockchain clients, connecting changes in software, peer relationships, and workloads to observed chain behavior. The conclusion presents it as a setting for investigating hypotheses through controlled interventions in a running system.

8 Conclusion

  • ChainSEED links configurable client and network conditions to observed transaction processing and consensus behavior.The conclusion describes using it to reproduce phenomena, test mechanisms and applications, and examine unexpected behavior.Source: §8 · p. 15
  • The paper concludes that controlled interventions in a running system provide a setting for investigating blockchain research hypotheses.Its studies demonstrate applications in security research and network measurement.Source: §8 · p. 15

A Existing Software Workflows

ChainSEED supports familiar wallet, contract-development, and automated-testing workflows through MetaMask, Remix, and Hardhat connected to its clients. The workflows completed on the emulated chain, including querying updated contract state from two execution nodes.

A Existing Software Workflows

  • 1 ETH transferred from Account A to Account B through MetaMask, and a Remix-deployed contract was updated from 0 to 42 and verified.Figures 8 and 9 illustrate the wallet and contract interfaces.Source: A Existing Software Workflows · p. 17, Figure 8 · p. 17, Figure 9 · p. 18
  • Hardhat deployed the integer-storage contract and updated its value from 0 to 42 through ChainSEED’s RPC interface.The script queried two execution nodes, both of which returned the updated value.Source: A Existing Software Workflows · pp. 17–18, Figure 10 · p. 18
  • Users can carry familiar wallet, contract-development, and automated-testing workflows into ChainSEED while its deployed clients process transactions and contract calls.The tools retain their usual interfaces, supporting application development and testing in a configurable blockchain environment.Source: A Existing Software Workflows · p. 18

B EthExplorer

EthExplorer provides a chain-level view with an epoch and slot overview alongside recent epochs and blocks.

B EthExplorer

C Ethereum Lookingglass

Ethereum Lookingglass provides a node-level view of beacon peer connections and selected-node metrics.

C Ethereum Lookingglass

D Transaction Workload Composition

Table 11 gives default sampling weights for transaction-generator categories; the weights specify probabilities, not exact proportions enforced in each interval.

D Transaction Workload Composition

Related papers

Loading 2610.31188v1…