0x0A-POINT_EVALUATION

Precompile Summary

Property	Value
Address	0x0A
Name	POINT_EVALUATION (KZG point evaluation, blobVerifyKzgProof)
Gas	50,000 (fixed)
Input	192 bytes: versioned_hash (32 bytes), z (32 bytes, evaluation point, BLS12-381 scalar field element), y (32 bytes, claimed evaluation, BLS12-381 scalar field element), commitment (48 bytes, compressed BLS12-381 G1 point), proof (48 bytes, compressed BLS12-381 G1 point)
Output	64 bytes: FIELD_ELEMENTS_PER_BLOB (32 bytes, big-endian) and BLS_MODULUS (32 bytes, big-endian) — returned on success
Introduced	Cancun hardfork (EIP-4844, March 2024)
Behavior	Verifies a KZG commitment opening proof. Checks that a polynomial committed to by commitment evaluates to y at point z, using a BLS12-381 pairing check internally. Also verifies that versioned_hash matches `0x01

---

Threat Surface

POINT_EVALUATION is the cryptographic linchpin of Ethereum’s blob data availability layer. Introduced alongside EIP-4844 (proto-danksharding) in the Cancun hardfork (March 2024), it is the only mechanism through which smart contracts can verify that specific data was included in an ephemeral blob transaction. Every rollup that relies on EIP-4844 for data availability — Optimism, Arbitrum, zkSync, Starknet, and the growing ecosystem of L2s — ultimately depends on the correctness of this single precompile for their security guarantees. A flaw in POINT_EVALUATION is a flaw in the data availability foundation of Ethereum’s rollup-centric roadmap.

The threat surface divides into four categories:

1. Cryptographic verification failures that break the blob-to-contract bridge. POINT_EVALUATION performs three distinct validations: versioned hash matching (SHA256-based), scalar field range checking (z and y must be less than BLS_MODULUS), and a BLS12-381 pairing check (the actual KZG proof verification). A failure in any one of these — accepting an invalid hash, accepting an out-of-range field element, or accepting a forged proof — severs the link between blob data and on-chain logic. The consequences are catastrophic: a rollup could be presented with a “valid” proof that its transaction data was posted in a blob when it was not, undermining the entire data availability guarantee that EIP-4844 provides.

2. BLS12-381 implementation divergence across clients. The pairing check at the heart of POINT_EVALUATION uses BLS12-381, a curve that was not previously used in Ethereum’s execution layer. Different clients use different BLS libraries — geth uses gnark-crypto, Nethermind uses a custom C# implementation, Reth uses blst — and each library has different code paths for point decompression, subgroup checking, and pairing computation. This is the same class of risk that produced CVE-2025-30147 for the BN254 precompiles, where a single library’s handling of invalid point encoding caused a consensus-critical divergence. BLS12-381 has a larger field and more complex decompression logic than BN254, making the attack surface broader.

3. Trusted setup dependency with irreversible consequences. KZG commitments rely on a structured reference string (SRS) produced by a trusted setup ceremony. Ethereum’s KZG Ceremony (2022-2023) collected contributions from 141,416 participants, and security requires that at least one was honest and destroyed their “toxic waste.” If the setup were compromised — all contributors colluding or a flaw in the ceremony protocol — an attacker could forge valid KZG proofs for arbitrary data, completely breaking blob data availability verification. Unlike a protocol bug that can be patched, a compromised trusted setup would require a new ceremony and a hard fork to replace the SRS.

4. Novelty and limited battle-testing. POINT_EVALUATION is the newest precompile on Ethereum, with roughly two years of mainnet exposure as of early 2026. Every other precompile has had seven or more years of adversarial testing. The combination of novel cryptography (BLS12-381 pairings), novel infrastructure (blob transactions, the beacon chain blob sidecar), and novel usage patterns (rollup proof verification) means the probability of undiscovered bugs is higher than for established precompiles. The execution-spec-tests suite provides coverage, but the interaction between POINT_EVALUATION and the broader blob lifecycle (blob propagation, pruning after ~18 days, reconstruction) introduces failure modes that unit tests cannot fully capture.

---

Smart Contract Threats

T1: Invalid Versioned Hash Acceptance (High)

The precompile verifies that versioned_hash == 0x01 || SHA256(commitment)[1:] — the first byte must be 0x01 (the version byte), and the remaining 31 bytes must match the SHA256 hash of the serialized commitment. This linkage is what ties the on-chain blobhash (accessible via the BLOBHASH opcode) to the specific KZG commitment used in the proof.

• Hash bypass via client implementation bug. If a client implementation skips or incorrectly performs the versioned hash check, an attacker could submit a proof against an arbitrary commitment that does not correspond to any actual blob. The pairing check would still verify (a valid proof for a valid commitment), but the commitment would not match the blob that was actually posted. The contract, trusting the precompile’s success, would accept the proof as evidence that specific data was in the blob when it was not.

• Version byte ambiguity. The version byte is 0x01 for EIP-4844. Future versioning schemes (e.g., for full danksharding) may introduce different version bytes. A client that performs a loose check (e.g., only verifying the SHA256 portion and ignoring the version byte) could accept proofs formatted for a future version that has different semantics.

• SHA256 dependency. The versioned hash computation uses SHA256, not keccak256. This means POINT_EVALUATION implicitly depends on the correctness of the SHA256 computation path in each client. A bug in the client’s internal SHA256 implementation (distinct from the SHA256 precompile at 0x02) could cause the versioned hash check to accept or reject incorrectly.

Why it matters: The versioned hash is the sole bridge between the blob transaction layer (beacon chain) and the execution layer (smart contracts). If this bridge can be spoofed, a rollup’s entire data availability guarantee collapses — an attacker can claim arbitrary data was posted to a blob and provide a “valid” proof for it.

T2: BLS12-381 Point Deserialization Errors (High)

The commitment and proof fields are compressed BLS12-381 G1 points, each 48 bytes. Decompression involves recovering the y-coordinate from the x-coordinate via a square root computation in a 381-bit prime field. This is computationally complex and has multiple failure modes.

• Invalid point acceptance. If a decompression implementation accepts a byte sequence that does not correspond to a valid G1 point — for example, an x-coordinate with no corresponding y-coordinate on the curve, or a point not in the correct prime-order subgroup — the subsequent pairing check operates on invalid inputs. Depending on the library, this could produce incorrect results (accepting an invalid proof) or, worse, different results across clients (consensus split).

• Cross-library divergence. The EVM client ecosystem uses multiple BLS12-381 libraries: blst (C, used by Reth and some Rust tooling), gnark-crypto (Go, used by geth), custom implementations (Nethermind, Besu). Each library may handle edge cases differently — infinity point encoding, non-canonical serialization, points on the twist rather than the curve. A single divergence on a single edge case is sufficient for a consensus split.

• CVE-2025-30147 precedent. The BN254 precompiles (0x06-0x08) suffered a consensus-critical bug (CVE-2025-30147) where the gnark-crypto library accepted a non-canonical point encoding that blst rejected. The same class of vulnerability applies to BLS12-381 in POINT_EVALUATION: different libraries applying different levels of strictness to point deserialization is a known and demonstrated risk pattern.

Why it matters: Point deserialization bugs are the most likely vector for a consensus split involving POINT_EVALUATION. The BLS12-381 curve’s larger field size and more complex serialization format compared to BN254 increase the surface area for such bugs.

T3: Field Element Validation (Medium)

The z and y inputs must be valid BLS12-381 scalar field elements — integers less than BLS_MODULUS (0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001). The precompile reads these as 32-byte big-endian integers and must reject values greater than or equal to the modulus.

• Range check omission. If a client implementation does not validate that z < BLS_MODULUS and y < BLS_MODULUS before proceeding with the pairing check, the behavior is undefined. Depending on the BLS library, an out-of-range scalar might wrap around modularly (producing a different but “valid” result), trigger an assertion failure (crashing the client), or produce a result that differs from other clients (consensus split).

• Big-endian interpretation. The 32-byte inputs are interpreted as big-endian unsigned integers. An implementation that uses the wrong byte order would compute a different value for z and y, leading to either incorrect rejection of valid proofs or incorrect acceptance of invalid ones.

• Boundary values. Values exactly equal to BLS_MODULUS must be rejected; values equal to BLS_MODULUS - 1 must be accepted. Off-by-one errors in the comparison (using <= instead of <, or vice versa) produce subtle bugs that may not surface in standard test cases but are exploitable with crafted inputs.

Why it matters: Field element validation is a prerequisite for the mathematical correctness of the pairing check. Out-of-range inputs can cause implementation-defined behavior that differs across clients, creating consensus risk. Even without a consensus split, a client that accepts out-of-range values could produce semantically incorrect verification results that mislead smart contracts.

T4: Blob Data Availability Fraud (Critical)

POINT_EVALUATION is the bridge between ephemeral blob data (pruned from the network after approximately 18 days) and persistent smart contract logic. Rollups use it to verify that their transaction data was posted in a blob, establishing the data availability guarantee that underpins their security model.

• Rollup data availability breach. If POINT_EVALUATION can be fooled into accepting a proof for data that was never actually in a blob, a rollup’s data availability guarantee is broken. An attacker could submit invalid rollup state transitions (e.g., stealing all funds from the rollup) and claim that the transaction data backing those transitions was posted in a blob. With no valid data to challenge against, fraud proofs become impossible, and validity proofs (for ZK-rollups) verify against fabricated data.

• Post-pruning exploitation window. After ~18 days, blob data is pruned from the consensus layer. If a vulnerability in POINT_EVALUATION is discovered but not exploited until after the relevant blob data is pruned, historical verification becomes impossible. The attack could retroactively invalidate data availability claims that were accepted during the pruning window.

• Cross-rollup systemic risk. Because all EIP-4844-based rollups use the same precompile and the same trusted setup, a vulnerability in POINT_EVALUATION is a vulnerability in every rollup simultaneously. This creates correlated risk across the entire L2 ecosystem — a single exploit could affect billions of dollars across multiple rollups.

Why it matters: Blob data availability is the foundational security assumption of Ethereum’s rollup-centric roadmap. POINT_EVALUATION is the enforcement mechanism for this assumption. A successful attack against it would be the most consequential exploit in Ethereum’s history, potentially undermining every rollup’s state integrity simultaneously.

T5: Trusted Setup Dependency (Informational)

KZG commitments rely on a structured reference string (SRS) generated through a multi-party computation ceremony. Ethereum’s KZG Ceremony (2022-2023) collected contributions from 141,416 participants across multiple rounds. The security assumption is 1-of-N honesty: if at least one contributor honestly generated their randomness and destroyed the “toxic waste” (their secret contribution), the SRS is secure.

• Theoretical compromise scenario. If the trusted setup were compromised (all 141,416 contributors colluded or were compromised, or a flaw in the ceremony protocol allowed toxic waste extraction), an attacker could forge valid KZG proofs for arbitrary polynomials. This would allow them to “prove” that any data was in any blob, completely breaking POINT_EVALUATION’s guarantees.

• Undetectable forgery. A forged KZG proof is indistinguishable from a legitimate one. Unlike a protocol bug that produces observable anomalies (e.g., inconsistent state roots), a trusted setup compromise allows silent, undetectable data availability fraud.

• Irremediable without hard fork. If the trusted setup were compromised, the only fix would be a new ceremony and a hard fork to replace the SRS. All historical KZG proofs verified under the compromised SRS would become untrustworthy.

Why it matters: The trusted setup is the cryptographic foundation that makes KZG commitments binding. While compromise is considered astronomically unlikely given the ceremony’s scale (141,416 contributors), it represents an irreducible assumption that cannot be verified or falsified. It is the one risk that no amount of code auditing or fuzzing can eliminate.

---

Protocol-Level Threats

P1: Newest Precompile — Least Battle-Tested

EIP-4844 was activated in the Cancun hardfork (March 2024), making POINT_EVALUATION the most recently introduced precompile on Ethereum. Every other precompile has had at least seven years of adversarial mainnet exposure. The combination of novel cryptography (BLS12-381 pairings), novel infrastructure (blob transactions, beacon chain blob sidecars), and novel usage patterns (rollup data availability verification) means the probability of undiscovered implementation bugs is inherently higher than for established precompiles.

The execution-spec-tests suite provides structured test coverage, but the interaction surface between POINT_EVALUATION and the broader blob lifecycle — blob propagation, blob sidecar availability, pruning after ~18 days, and reconstruction from erasure-coded data — introduces failure modes that isolated unit tests cannot capture.

P2: SHA256 Dependency Chain

The versioned hash computation uses SHA256 internally (versioned_hash == 0x01 || SHA256(commitment)[1:]). This creates a dependency on each client’s SHA256 implementation. Note that this is the client’s internal SHA256 computation, not necessarily the SHA256 precompile at address 0x02 (though some clients may share code). A bug in the SHA256 path used by POINT_EVALUATION could cause the versioned hash check to silently accept or reject incorrectly, cascading into data availability verification failures.

P3: Fixed Gas Cost vs. Pairing Complexity

The POINT_EVALUATION precompile charges a fixed 50,000 gas regardless of input. The underlying BLS12-381 pairing check is computationally expensive (involving Miller loop computation and final exponentiation). If a future optimization reduces the gas cost, or if hardware changes make the computation cheaper for attackers but not for validators, the fixed cost may become a DoS vector. Conversely, if the 50,000 gas is insufficient to cover worst-case computation time on slower validator hardware, block processing may be delayed.

The fixed cost model is simpler than MODEXP’s variable pricing but trades off adaptability: there is no mechanism to adjust for edge-case inputs that are more expensive to process (e.g., inputs that exercise slow paths in point decompression).

P4: Cross-Chain Absence

L2 chains and alternative EVM-compatible networks that have not adopted EIP-4844 do not have the POINT_EVALUATION precompile. A contract that calls address 0x0A on such a chain will either revert (if the address has no code and the chain treats precompile calls to unknown addresses as failures) or execute against an EOA/contract at that address (if one exists), producing undefined behavior. Cross-chain contracts that assume POINT_EVALUATION is universally available will fail silently or produce incorrect results on chains without EIP-4844 support.

P5: Future Extension — EIP-8149 Multi-Point Evaluation

EIP-8149 proposes a multi-point evaluation precompile that would allow batch verification of multiple KZG opening proofs in a single call, amortizing the cost of the pairing computation. This would improve gas efficiency for rollups that verify multiple blob data points per transaction. However, it also introduces new attack surface: batch verification with maliciously crafted subsets, interaction between valid and invalid proofs in the same batch, and potential for new implementation divergence across clients.

---

Edge Cases

Edge Case	Behavior	Security Implication
versioned_hash with wrong version byte (not 0x01)	Call fails (returns empty)	Correct behavior; prevents proofs formatted for future versioning schemes from being accepted under current rules
versioned_hash doesn’t match SHA256(commitment)	Call fails (returns empty)	Correct behavior; prevents proof verification against a commitment that doesn’t correspond to the actual blob
z = 0	Valid evaluation point; precompile proceeds normally	No security issue — 0 is a valid element of the scalar field
y = 0	Valid evaluation result; precompile proceeds normally	No security issue — 0 is a valid field element and a legitimate polynomial evaluation result
z >= BLS_MODULUS	Call fails (returns empty)	Correct behavior; out-of-range scalar field elements must be rejected. A client that does not perform this check risks undefined behavior in the pairing computation (T3)
y >= BLS_MODULUS	Call fails (returns empty)	Same as above; both z and y must be strictly less than BLS_MODULUS
Invalid compressed point (not on BLS12-381 G1 curve)	Call fails (returns empty)	Correct behavior; decompression must validate that the point lies on the curve and in the correct subgroup. Implementation bugs here are the most likely consensus-split vector (T2)
commitment = point at infinity	Edge case in decompression; behavior depends on library handling of the infinity encoding	Libraries may encode/decode the point at infinity differently. Must be tested explicitly across all clients to ensure consistent behavior
Input length != 192 bytes	Call fails (returns empty)	Correct behavior; strict input length validation prevents parsing ambiguity
Proof for a different polynomial	Pairing check fails; call returns empty	Correct behavior; the KZG verification equation detects mismatched commitment/proof/evaluation tuples
Valid proof with correct inputs	Returns 64 bytes: FIELD_ELEMENTS_PER_BLOB (4096) and BLS_MODULUS	Contracts must check that the return data is exactly 64 bytes and decode both values correctly; ignoring the return data is a vulnerability (Scenario A)

---

Real-World Exploits

Exploit 1: No Known Direct Exploits (Precompile Active Since March 2024)

Root cause: N/A — no confirmed exploitation of POINT_EVALUATION has occurred as of early 2026.

Details: POINT_EVALUATION is the newest Ethereum precompile, with approximately two years of mainnet exposure. Multiple client teams have invested heavily in testing, and the execution-spec-tests repository contains extensive KZG-specific test vectors covering valid proofs, invalid proofs, edge-case field elements, and malformed inputs. The Ethereum Foundation’s dedicated cryptography team and external auditors (e.g., Trail of Bits, Sigma Prime) have reviewed the BLS12-381 implementations used by major clients.

However, the absence of known exploits should not be interpreted as proof of correctness. The BN254 precompiles operated for years before CVE-2025-30147 was discovered, and MODEXP has produced recurring consensus bugs despite extensive testing. POINT_EVALUATION’s relative novelty and cryptographic complexity make it a high-priority target for future security research.

POINT_EVALUATION’s role: The precompile is the sole on-chain mechanism for blob data verification. Its correctness is assumed by every EIP-4844-based rollup, making it a high-value target whose exploitation would have systemic consequences.

Impact: No impact to date, but the potential impact of a future exploit is critical — simultaneous compromise of data availability guarantees across all EIP-4844-based rollups.

References:

• EIP-4844: Shard Blob Transactions
• Ethereum KZG Ceremony
• execution-spec-tests: KZG Point Evaluation Tests

---

Exploit 2: CVE-2025-30147 — BN254 Consensus Bug as a Precedent for BLS12-381 Risk

Root cause: Different BLS/BN libraries applied different strictness levels to elliptic curve point deserialization, causing one client to accept an input that another client rejected.

Details: In early 2025, CVE-2025-30147 was disclosed affecting the BN254 precompiles (0x06-0x08). The gnark-crypto library (used by geth) accepted a non-canonical encoding of a BN254 G1 point that the blst library (used by other clients) rejected. A single transaction containing this non-canonical encoding would cause geth nodes to produce a different execution result than blst-based nodes, splitting the network along client boundaries.

While this vulnerability affected BN254 (a different curve), the same class of bug applies directly to BLS12-381 in POINT_EVALUATION. BLS12-381 has a larger field (381-bit vs. 254-bit prime), more complex point compression (due to the larger field requiring different square root algorithms), and different serialization conventions. The BLS12-381 libraries used across clients are younger and less battle-tested than their BN254 counterparts, making analogous deserialization divergence a realistic concern.

POINT_EVALUATION’s role: POINT_EVALUATION accepts two compressed BLS12-381 G1 points (commitment and proof) as input. Any discrepancy in how clients deserialize these points would manifest as a consensus split triggered by a crafted POINT_EVALUATION call.

Impact: CVE-2025-30147 was patched before mainnet exploitation. Its existence demonstrates that cross-library point deserialization divergence is a practical, not merely theoretical, risk for pairing-based precompiles.

References:

• CVE-2025-30147: gnark-crypto BN254 Point Validation Bug
• geth Security Advisory

---

Exploit 3: Optimism Fault Proof Integration — POINT_EVALUATION as a Critical Dependency

Root cause: N/A — this is a systemic dependency observation, not a specific exploit.

Details: Optimism’s fault proof system integrates POINT_EVALUATION verification as part of its dispute resolution mechanism. When a challenger disputes a proposed L2 state root, the fault proof game may need to verify that specific transaction data was posted in a blob. This verification is performed via POINT_EVALUATION. If the precompile were compromised, the fault proof system’s ability to adjudicate disputes correctly would be undermined — a malicious proposer could submit invalid state transitions backed by forged blob data proofs, and challengers would be unable to prove fraud because the verification mechanism itself is compromised.

This integration pattern is representative of how all optimistic rollups will interact with POINT_EVALUATION as they adopt EIP-4844 for data availability. The precompile is not just a cryptographic primitive; it is a load-bearing component of rollup security infrastructure.

POINT_EVALUATION’s role: Directly embedded in the critical path of L2 dispute resolution.

Impact: A POINT_EVALUATION vulnerability would not just affect individual transactions — it would undermine the entire dispute resolution mechanism that prevents rollup operators from stealing user funds.

References:

• Optimism Fault Proof Specification
• EIP-4844: Shard Blob Transactions

---

Attack Scenarios

Scenario A: Rollup Contract That Does Not Check Return Value

contract VulnerableRollup {
    address constant POINT_EVALUATION = address(0x0A);
 
    mapping(bytes32 => bool) public verifiedBlobs;
 
    // VULNERABLE: does not check the return value of the precompile call.
    // A failed verification (invalid proof) returns empty data, but the
    // contract treats any non-reverting call as success.
    function verifyBlobInclusion(
        bytes32 versionedHash,
        bytes32 z,
        bytes32 y,
        bytes memory commitment,
        bytes memory proof
    ) external {
        bytes memory input = abi.encodePacked(
            versionedHash,
            z,
            y,
            commitment,
            proof
        );
 
        (bool success, bytes memory result) = POINT_EVALUATION.staticcall(input);
 
        // BUG: only checks that the call didn't revert at the EVM level,
        // not that the precompile returned valid output.
        // POINT_EVALUATION returns empty bytes on verification failure,
        // which still results in success=true for staticcall.
        require(success, "precompile call failed");
 
        // Should also check: require(result.length == 64, "verification failed");
        // And decode FIELD_ELEMENTS_PER_BLOB and BLS_MODULUS from result.
 
        verifiedBlobs[versionedHash] = true;
    }
 
    function submitBatch(
        bytes32 versionedHash,
        bytes calldata batchData
    ) external {
        require(verifiedBlobs[versionedHash], "blob not verified");
        // Process batch under the assumption that blob data is available...
        // An attacker who bypassed verification can submit arbitrary batch data
    }
}
 
// Attack:
// 1. Attacker calls verifyBlobInclusion with an invalid proof
// 2. POINT_EVALUATION returns empty bytes (verification failed),
//    but staticcall returns success=true
// 3. verifiedBlobs[versionedHash] is set to true
// 4. Attacker calls submitBatch with fabricated batch data
// 5. Rollup processes invalid state transitions as if backed by valid blob data

Scenario B: Mismatched Versioned Hash Exploitation

contract BlobVerifier {
    address constant POINT_EVALUATION = address(0x0A);
 
    // VULNERABLE: uses a user-supplied versioned hash without validating
    // it against the actual blob hashes in the current block.
    function verifyBlobData(
        bytes32 userSuppliedHash,
        uint256 evaluationPoint,
        uint256 claimedValue,
        bytes calldata commitment,
        bytes calldata proof
    ) external view returns (bool) {
        // Should use: bytes32 actualHash = blobhash(blobIndex);
        // and verify: require(userSuppliedHash == actualHash);
 
        bytes memory input = abi.encodePacked(
            userSuppliedHash,
            bytes32(evaluationPoint),
            bytes32(claimedValue),
            commitment,
            proof
        );
 
        (bool success, bytes memory result) = POINT_EVALUATION.staticcall(input);
 
        // Even if the precompile succeeds, this only proves that the
        // commitment/proof/evaluation are internally consistent --
        // it does NOT prove the commitment corresponds to any blob
        // in the current (or any) block.
        return success && result.length == 64;
    }
}
 
// Attack:
// 1. Attacker generates their own KZG commitment for arbitrary data
// 2. Computes versioned_hash = 0x01 || SHA256(commitment)[1:]
// 3. Generates a valid KZG opening proof for their chosen z and y
// 4. Calls verifyBlobData with the self-generated hash, commitment, and proof
// 5. POINT_EVALUATION succeeds because the proof is mathematically valid
// 6. But the commitment has nothing to do with any actual blob on-chain
// 7. The contract is tricked into accepting arbitrary data as "blob-verified"

Scenario C: Cross-Chain Deployment Where POINT_EVALUATION Is Absent

contract CrossChainBlobBridge {
    address constant POINT_EVALUATION = address(0x0A);
 
    // Deployed on an L2 that does NOT support EIP-4844.
    // Address 0x0A is either an EOA (no code) or doesn't exist as a precompile.
    function verifyAndBridge(
        bytes32 versionedHash,
        bytes32 z,
        bytes32 y,
        bytes calldata commitment,
        bytes calldata proof,
        bytes calldata payload
    ) external {
        bytes memory input = abi.encodePacked(
            versionedHash, z, y, commitment, proof
        );
 
        (bool success, bytes memory result) = POINT_EVALUATION.staticcall(input);
 
        // On a chain without EIP-4844:
        // - staticcall to 0x0A (an EOA) returns success=true, result=empty
        // - Contract may interpret empty result as a valid verification
        //   depending on the check below
 
        // VULNERABLE: this check passes on chains without the precompile
        // because staticcall to an EOA returns (true, "")
        if (!success) {
            revert("verification failed");
        }
 
        // Missing: require(result.length == 64, "not a valid precompile response");
 
        _processPayload(payload);
    }
 
    function _processPayload(bytes calldata payload) internal {
        // Bridge logic that trusts the blob verification above
    }
}
 
// Attack:
// 1. Contract is deployed on an L2 without EIP-4844 support
// 2. Address 0x0A has no precompile code; staticcall returns (true, "")
// 3. Attacker calls verifyAndBridge with any inputs
// 4. The success check passes (staticcall to EOA succeeds)
// 5. Payload is processed without any actual blob verification
// 6. Attacker can bridge arbitrary data without valid blob backing

---

Mitigations

Threat	Mitigation	Implementation
T1: Invalid versioned hash	Validate versioned hash against BLOBHASH opcode	bytes32 actual = blobhash(blobIndex); require(actual == versionedHash && actual != bytes32(0), "invalid blob reference");
T2: BLS12-381 deserialization divergence	Client teams must fuzz BLS12-381 libraries against each other	Cross-client differential fuzzing with shared test vectors; mandatory consensus tests for all point encoding edge cases
T3: Field element range errors	Client implementations must validate z, y < BLS_MODULUS	Range check before any arithmetic; reject with empty return on failure
T4: Blob data availability fraud	Verify blob reference in the same transaction as blob submission	Use BLOBHASH opcode to confirm blob presence in the current block; do not rely solely on user-supplied versioned hashes
T4: Post-pruning exploitation	Archive blob data beyond the ~18-day pruning window	Rollups should maintain independent blob data archives or use third-party data availability services as backup
T5: Trusted setup compromise	No on-chain mitigation; rely on ceremony security	Monitor for cryptographic breakthroughs; prepare contingency plan for SRS replacement via hard fork
Scenario A: Unchecked return value	Validate precompile return data length and contents	require(result.length == 64, "point evaluation failed"); (uint256 fieldElements, uint256 blsModulus) = abi.decode(result, (uint256, uint256));
Scenario C: Missing precompile on L2	Check for precompile existence before relying on it	require(result.length == 64, "precompile not available"); — empty return from EOA call is distinguishable from valid 64-byte output

Compiler/EIP-Based Protections

• EIP-4844 (Cancun, March 2024): Introduced blob transactions, the BLOBHASH opcode, and the POINT_EVALUATION precompile. Defines the versioned hash format (0x01 || SHA256(commitment)[1:]) and the 50,000 fixed gas cost. The specification mandates strict input validation: exactly 192 bytes, field elements within range, valid compressed points, matching versioned hash.
• EIP-4844 KZG Ceremony (2022-2023): The trusted setup ceremony with 141,416 contributors. The resulting SRS (structured reference string) is hardcoded into all client implementations and used by POINT_EVALUATION for proof verification. Security rests on the 1-of-N honesty assumption.
• execution-spec-tests: The Ethereum Foundation maintains comprehensive test vectors for POINT_EVALUATION covering valid proofs, invalid proofs, boundary field elements, malformed inputs, and cross-client consistency. All client implementations must pass these tests before release.
• EIP-8149 (Proposed): Multi-point evaluation precompile for batch KZG proof verification. Would reduce gas costs for rollups verifying multiple blob data points and amortize the pairing computation, but introduces new implementation and attack surface.
• BLOBHASH opcode: Returns the versioned hash of a blob attached to the current transaction. Contracts should always use BLOBHASH to obtain versioned hashes rather than accepting them as user-supplied parameters, ensuring the hash corresponds to an actual blob in the current block.

---

Severity Summary

Threat ID	Category	Severity	Likelihood	Real-World Precedent
T1	Smart Contract	High	Low	No known exploitation, but the versioned hash check is the sole link between blobs and on-chain logic. A bypass would be catastrophic for rollup security.
T2	Protocol	High	Medium	CVE-2025-30147 demonstrated that cross-library point deserialization divergence is a practical risk for pairing-based precompiles. BLS12-381 has a larger attack surface than BN254.
T3	Smart Contract	Medium	Low	No known exploitation, but field element range checking is a common source of subtle bugs in cryptographic implementations. Boundary-value errors are difficult to detect without targeted fuzzing.
T4	Smart Contract / Protocol	Critical	Low	No known exploitation. Impact would be systemic — simultaneous compromise of data availability across all EIP-4844-based rollups. The precompile’s novelty increases the probability of undiscovered bugs.
T5	Protocol	Informational	Negligible	No evidence of trusted setup compromise. The KZG Ceremony’s scale (141,416 contributors) makes collusion astronomically unlikely. Remains an irreducible cryptographic assumption.
P1	Protocol	Medium	Medium	All new precompiles carry elevated risk due to limited battle-testing. POINT_EVALUATION’s cryptographic complexity amplifies this baseline risk.
P2	Protocol	Low	Low	No known SHA256 bugs affecting POINT_EVALUATION. Dependency is indirect but creates a potential cascade path.
P3	Protocol	Low	Low	Fixed 50,000 gas cost appears adequate for current hardware. May need adjustment if computation costs change significantly.
P4	Smart Contract	Medium	Medium	Cross-chain deployment failures are a known pattern for newer EIPs. Contracts must validate precompile availability.
P5	Protocol	Informational	N/A	EIP-8149 is a proposal; no implementation risk until adopted.

---

Related Precompiles

Precompile	Relationship
SHA256 (0x02)	POINT_EVALUATION uses SHA256 internally to compute the versioned hash (version byte 0x01 prepended to the truncated SHA256 of the commitment). A bug in the SHA256 computation path could cascade to incorrect versioned hash validation in POINT_EVALUATION.
BN256PAIRING (0x08)	Both precompiles perform elliptic curve pairing checks — BN256PAIRING on the BN254 curve (for SNARK verification) and POINT_EVALUATION on BLS12-381 (for KZG proof verification). They share the same class of implementation risks: point deserialization divergence, subgroup checking, and cross-library consistency. CVE-2025-30147 in BN256PAIRING is a direct precedent for potential BLS12-381 bugs.
ECRECOVER (0x01)	Both are cryptographic verification precompiles that serve as authentication primitives. ECRECOVER verifies ECDSA signatures (secp256k1), while POINT_EVALUATION verifies KZG opening proofs (BLS12-381). Both return empty output on failure rather than reverting, creating the same class of “unchecked return value” vulnerabilities in calling contracts.
MODEXP (0x05)	Both perform complex cryptographic computations that are expensive relative to typical EVM operations. MODEXP uses variable gas pricing based on input dimensions; POINT_EVALUATION uses fixed gas pricing. Both face cross-client implementation divergence risks due to reliance on different underlying cryptographic libraries.