Full Report
Ethereum has implemented several EVMs and consensus clients, which is important for security. If there's a horrible double-spend issue, it's unlikely that it will be on two different clients. Unfortunately, this has created an entirely new bug class: consensus disagreements. If two implementations differ at all, then these two stacks will come to different conclusions on values, resulting in a chain split. Geth and Nethermind are two such EVM implementations. A competitor in the Pectra Audit contest noticed that there is a difference in the results of the BLS12-381 pre-compile. The specification for this smart contract had the following: "If any input is the infinity point, pairing result will be 1. Protocols may want to check and reject infinity points prior to calling the precompile." This has two interpretations: The pair may be ignored, where P or Q is infinity. The precompile should return 1 and the multi-pairing shouldn't be computed. The author intended 1. Nethermind had implemented 2, and Geth had implemented 1. So, it was decided to use the Geth-compliant implementation in this case. Consensus issues are super nasty; they quickly lead to the division of chains. Unfortunately, it's nearly impossible to be perfectly compliant with every little feature of a piece of software.
Analysis Summary
# Vulnerability: Consensus Disagreement in BLS12-381 Pre-compile Implementation
## CVE Details
- CVE ID: N/A (This appears to be a specification/implementation divergence causing non-security-critical consensus failure rather than a traditional security vulnerability that allows unauthorized access or resource corruption, thus likely not assigned a standard CVE.)
- CVSS Score: N/A (Not applicable for non-security-impacting consensus divergence, though chain split is critical impact)
- CWE: CWE-20 (Improper Input Validation) related to misinterpretation of specification, leading to divergent client behavior.
## Affected Systems
- Products: Ethereum EVM Implementations (Specifically noted: Nethermind and Geth)
- Versions: Versions of Nethermind and Geth that implement the divergent logic for the BLS12-381 pre-compile when receiving the infinity point as input.
- Configurations: Any deployment relying on consensus between clients using the differing implementations for the BLS12-381 multi-pairing pre-compile operation.
## Vulnerability Description
A divergence exists in the interpretation of the specification for the BLS12-381 pre-compile smart contract regarding input containing the "infinity point."
The specification states: "If any input is the infinity point, pairing result will be 1." This was interpreted in two ways by major clients:
1. **Interpretation 1 (Author/Geth-compliant):** The pre-compile should return `1` immediately, bypassing multi-pairing computation if P or Q is infinity.
2. **Interpretation 2 (Nethermind-compliant):** The pre-compile might compute the pairing result based on a different logic path or return a different value when infinity points are encountered (implied to be non-1 or calculated result).
This difference in output (`1` vs. another value) for the same input causes clients to reach different conclusions on state values, leading directly to a **chain split** consensus failure.
## Exploitation
- Status: Not a traditional exploit; it is a consensus failure bug triggered by standard, valid inputs that reveal differing client interpretations.
- Complexity: Low (Requires only running two different EVM clients against the same transaction stream to expose the divergence).
- Attack Vector: Network (Through the propagation of transactions that utilize the affected pre-compile).
## Impact
- Confidentiality: No direct impact reported.
- Integrity: **High** (Leads to consensus failure and chain split, potentially resulting in transactional finality issues and double-spends across split chains).
- Availability: **High** (Leads to network divergence, severely impacting chain availability and reliability).
## Remediation
### Patches
- **Resolution:** The issue was addressed by standardizing on the Geth-compliant implementation (returning `1` when an input is the infinity point). Specific patch versions depend on the respective client (Geth, Nethermind, etc.). Users must upgrade to versions incorporating this standardized logic.
### Workarounds
- Temporarily, operators could restrict validator/execution nodes only to instances running the agreed-upon compliant client logic (e.g., Geth-compliant behavior) until all clients are updated to prevent split visibility.
## Detection
- Indicators of Compromise: Observing block forks originating from clients reporting different transaction finality or state roots after executing transactions that utilize the BLS12-381 pre-compile with infinity point inputs.
- Detection Methods and Tools: Monitoring network consensus health for unusual divergences between client types or divergence in block validation results.
## References
- Fellowship of Ethereum Magicians Forum: defang dot at/t/bls12-381-pairing-consensus-issue/14469