Adversarial Performance Engineering
For many years, performance and security engineering were strictly separated disciplines. The former validated how concurrent requests impact user experience, while the latter focused on confidentiality, integrity, and availability of mission-critical applications.
In their recent paper, Qi et al. demonstrate that performance characteristics can become security properties. They studied how, in blockchain-based systems such as Ethereum, latency contributed to instability and caused an unexpected attack surface. Their research shows why performance engineering and cybersecurity are increasingly connected disciplines.
Latency becomes an attack vector
When the time between blocks is reduced to improve throughput, blocks have less time to propagate through the network. As a result, forks increase, and an attacker can exploit this ambiguity. In this case, latency becomes an attack vector. A benign validator builds on older blocks because network latency prevents it from receiving the newest block in time. When an attacker behaves as if it were experiencing latency, similarly to a slow node, but already has an up-to-date view of the blockchain and creates a fork on earlier blocks, it becomes a security problem. Such malicious behavior is difficult to distinguish from poor system performance. The authors call this plausible deniability.
Where Security and Performance intersect
In a blockchain-based system such as Ethereum, the same observable system behavior can have either a performance cause or a security cause. A fork could mean:
A. the network is slow
B. a node is overloaded
C. traffic is bursty
D. the system is incorrectly configured
E. an attacker is deliberately creating behavior that looks like A–D.
Traditional monitoring based purely on thresholds becomes much less useful in such circumstances.
Performance tests conducted only under benign conditions may validate a configuration that is unsafe under attack
Increasing slot length improves the probability of avoiding forks, but reduces normalized throughput. Introducing adversarial validators moves the acceptable operating point further toward longer slot times. So a configuration that appears perfectly acceptable during conventional performance testing can become unacceptable once you consider adversarial behavior.
Why does combined Performance and Security expertise become important?
Historically, performance engineering focused on the impact of increasing load and measured latency. Security engineering, by contrast, targeted classical adversarial manipulations of systems. In fact, system risks span a much broader spectrum and depend on load, Latency, Capacity, Configuration, and Threat.
What happens when an attacker manipulates a system performance characteristic?
#Performance anomalies can be security signals
Latency, queueing, retransmissions, resource exhaustion, connection saturation, and timing anomalies shouldn't automatically be classified as operational issues. They may indicate intentional manipulation.
#Security attacks can manifest primarily as performance degradation
Not every attack produces a clear signature such as malware, unauthorized access, or an IOC. An attack may instead appear as:
latency → synchronization failure → instability → reduced throughput.
Without performance expertise, the security team may see the consequence without understanding the mechanism.
#Baselines become essential for detecting attacks
To determine whether latency is malicious, you first need to understand what normal latency looks like. That requires performance engineering: distributions, percentiles, workload correlation, saturation behavior, topology, queueing, dependency latency, and expected behavior under peak conditions.
#Performance tuning can change the attack surface
A parameter change intended to increase throughput may inadvertently reduce security margins. Performance optimization therefore cannot always be performed independently of threat modeling.
#Resilience requires adversarial performance testing
Traditional performance testing asks: Can the system handle 2× peak load?
The approach suggested by Qi et al. is closer to: Can the system maintain acceptable performance and security properties at 2× peak load while selected components behave adversarially?
From Performance Engineering to Security-Aware Performance Engineering
The paper points toward an interesting evolution of performance engineering. Traditional performance engineering tends to optimize:
Latency, Throughput, Errors, Resource Utilization. Security engineering adds: Attack Surface, Integrity, Availability, Adversarial Behavior. Together, the discipline optimizes for something closer to Performance + Security + Resilience under both expected and adversarial conditions.
Performance engineers establish how the system behaves as load, latency, and resources change. Security engineers establish how an adversary could intentionally manipulate those conditions. Observability then becomes the common analytical layer connecting the two.
Why does this become even more relevant in the future?
Modern distributed systems, cloud platforms, APIs, microservices, and AI/agentic architectures increasingly depend on timing, distributed state, queues, retries, concurrency, and resource allocation. Those are simultaneously performance mechanisms and potential security control points.
Performance is increasingly part of the security boundary
You cannot reliably determine whether abnormal system behavior is malicious unless you understand how the system behaves under normal and abnormal performance conditions. Conversely, you cannot safely optimize performance without understanding how those optimizations alter the system's security and resilience characteristics.
That creates a strong case for combining performance engineering, observability, security engineering, and resilience testing rather than treating them as separate assurance silos.
Happy Performance + Security Engineering:)
References:
Qi, S., Zhao, Q., Liu, Z., Zhou, M., Shen, M., Zhang, P., & Sun, Y. (2026). Modeling the Performance-Security Trade-Off of Gasper's Block Proposal Mechanism Under Latency-Driven Attacks. IEEE Transactions on Information Forensics and Security, 21, 1213–1227. https://doi.org/10.1109/TIFS.2026.3651978
Comments