Exploring Blockchain Replay Attacks: Five Typical Examples
November 4, 2025
6 mins read
This article dives into the nature of replay attacks, their various forms, and effective strategies to guard against them. By understanding and mitigating these attacks, we can enhance the security and reliability of blockchain systems.
Replay attacks are a significant threat in the realm of blockchain technology, where the security of transactions is paramount. This article dives into the nature of replay attacks, their various forms, and effective strategies to guard against them. By understanding and mitigating these attacks, we can enhance the security and reliability of blockchain systems.
I. What is a Replay Attack?
A replay attack occurs when an attacker intercepts and manipulates data transmissions over a network. In blockchain, this involves reusing valid transactions to exploit the system. Preventing replay attacks is crucial to maintain the integrity and security of blockchain transactions.
II. Prerequisites
Understanding Signatures and Authentication in Ethereum
To grasp replay attacks, one must understand how signatures and authentication work in Ethereum. This includes knowledge of ECDSA (Elliptic Curve Digital Signature Algorithm) key generation, signing, and verification processes. Familiarity with Ethereum signature standards, specifically EIP-191 and EIP-712, is also essential.
Recommended Reading
-
Understanding Ethereum Signature Standards EIP-191 & EIP-712
-
ECDSA Signatures
(Note: The code examples in this article are for demonstration purposes and should not be used in production without a thorough security review.)
III. What is a Blockchain Replay Attack?
Definition and Explanation
In blockchain, a replay attack involves reusing a valid transaction to manipulate the system for personal gain. This can be done by copying transactions to another chain or modifying the signature, thus bypassing validation checks.
Common Techniques Used in Replay Attacks
-
Copying transactions to different chains
-
Modifying transaction signatures
-
Exploiting validation mechanisms
Types of Blockchain Replay Attacks
1. Missing Application Nonce Replay Attack
Explanation of Application Nonce
An application nonce is a unique identifier used once per transaction to prevent replay. Its absence can lead to the reuse of signatures, allowing attackers to resend transactions.
How Missing Application Nonce Replay Attacks Work
-
A message is signed without a nonce.
-
An attacker intercepts and copies this signature.
-
The attacker reuses the signature to resend the transaction.
Mitigating Against Missing Nonce Replay Attacks
To prevent this, include a nonce in each transaction:
This nonce is checked to ensure the signature is not reused.
Example of Nonce Replay Attack
In the KYCRegistry contract example, if KYC status is revoked and the signature is replayed, the attacker can regain KYC status. Adding a nonce to the signature can prevent this vulnerability.
2. Hard Fork Replay Attacks
What is a Hard Fork?
A hard fork involves a significant protocol change that results in two separate ledgers: the original and the forked.
How Hard Fork Replay Attacks Work
Transactions valid on the original ledger can be replayed on the new ledger if both share the same transaction and address formats.
Mitigating Against Hard Fork Replay Attacks
-
Strong Replay Protection: Attach unique markers to transactions on the new ledger.
-
Opt-in Replay Protection: Users manually adjust transactions to prevent replays.
Examples of Hard Fork Replay Attacks
-
Ethereum Classic Hard Fork: Post-fork, transactions were valid on both Ethereum (ETH) and Ethereum Classic (ETC), leading to exploits.
-
Ethereum Merge: Replay attacks occurred due to shared chain IDs between Ethereum PoW and the post-merge Mainnet.
3. Cross-Chain Replay Attacks
Explanation of Cross-Chain Replay Attacks
These attacks occur when transactions from one blockchain are replayed on another, often due to interoperable protocols.
Rollups and Cross-Chain Replay
Transactions from L1 (Layer 1) to L2 (Layer 2) can be replayed if smart contracts have the same address but different implementations.
Mitigating Against Cross-Chain Replay Attacks
Use chain-specific signature schemes like EIP-155, which include the chain ID in the signed message.
4. Signature Malleability Replay Attack
Explanation of Signature Malleability
Due to elliptic curve symmetry, two valid signatures can exist for a single point, allowing attackers to create a second valid signature without the private key.
Example of Signature Malleability
Using ecrecover without restricting the s value allows for two valid signatures, making the contract vulnerable.
Mitigating Against Signature Malleability Replay Attacks
Restrict the s value to only the lower half:
Using OpenZeppelin's ECDSA library (version 4.7.3 or greater) is recommended.
5. Cryptographic Nonce Reuse Replay Attack
Explanation of Cryptographic Nonce Reuse
Reusing the nonce (k value) in ECDSA signatures allows attackers to extract the private key.
How Nonce Reuse Compromises Security
If the nonce is reused, the private key can be computed, compromising the signer's account.
Mitigating Against Nonce Reuse Replay Attacks
Ensure each nonce (k value) is unique and unpredictable. Using OpenZeppelin's ECDSA library (version 4.7.3 or greater) helps prevent this issue.
IV. Preventing Blockchain Replay Attacks
General Strategies for Prevention
-
Include a unique nonce in each signature.
-
Set and check expiration dates for signatures.
-
Restrict the s value to a single half.
-
Include chain IDs in signatures.
-
Use unique identifiers for multiple messages within the same contract or chain.
Example Code for Implementing Replay Resistance
solidity
struct ReplayResistantMessage {
uint256 number;
uint256 deadline;
uint256 nonce;
}
bytes32 public constant REPLAY_RESISTANT_MESSAGE_TYPEHASH =
keccak256("Message(uint256 number,uint256 deadline,uint256 nonce)");
mapping(address => mapping(uint256) => bool) public noncesUsed;
mapping(address => uint256) public latestNonce;
_function getSignerReplayResistant(
uint256 message,
uint256 deadline,
uint256 nonce,
uint8 _v,
bytes32 _r,
bytes32 s
)
public
view
returns (address)
{
bytes32 hashStructOfDomainSeparator = i_domain_separator;
_ bytes32 hashedMessage = keccak256(
abi.encode(
REPLAY_RESISTANT_MESSAGE_TYPEHASH,
ReplayResistantMessage({ number: message, deadline: deadline, nonce: nonce })
)
);_
_ bytes32 digest = keccak256(abi.encodePacked(bytes1(0x19), bytes1(0x01), hashStructOfDomainSeparator, hashedMessage));
return ecrecover(digest, _v, _r, s);
}
_function verifySignerReplayResistant(
ReplayResistantMessage memory message,
uint8 _v,
bytes32 _r,
bytes32 s,
address signer
)
public
returns (bool)
{
require(!noncesUsed[signer][message.nonce], "Need unique nonce");
noncesUsed[signer][message.nonce] = true;
latestNonce[signer] = message.nonce;
_ require(block.timestamp < message.deadline, "Expired");_
_ address actualSigner = getSignerReplayResistant(message.number, message.deadline, message.nonce, _v, _r, s);
require(actualSigner != address(0));
require(signer == actualSigner);
_ if (uint256(s) > 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0) {
revert("bad s");
}
_ return true;
}_
Disclaimer:
This article references multiple sources and is based on a code review of ChatGPT 4o. Some code may not be optimized, please consider and review carefully before applying it to your product.
Conclusion
Blockchain replay attacks can exploit various vulnerabilities in smart contracts and transaction mechanisms. By implementing proper nonce management, signature restrictions, and using up-to-date libraries, developers can significantly reduce the risk of these attacks. Thorough testing and auditing are essential to ensure the security and integrity of blockchain systems.
Experience verifiable data in action - Join the zkDatabase live demo!
Book a Demo
