📄Verification and Sepecification

Required Checks in the Verification:

Before verifying a signature, certain checks are performed to ensure the provided signature components and public key are valid. Here's what each bullet point means:

• Verify that both r - s values are greater than 0 and less than the curve order.

  • r and s are the two components of an ECDSA signature. They should be positive values and must be less than the order of the elliptic curve group. This ensures they are valid scalar values in the elliptic curve's finite field.

• Verify that s is equal to or less than half of the order of the subgroup to prevent signature malleability.

  • Signature malleability refers to the ability to alter a signature without invalidating it. By ensuring s is less than or equal to half the curve's order, the protocol reduces the risk of having two valid signatures for the same message, which is a common ECDSA vulnerability.

• Verify that the point formed by (x, y) values is on the curve and both components are in between 0 and the p value of the curve.

  • The public key is a point on the elliptic curve defined by its x and y coordinates. This check ensures that the provided point lies on the curve. Additionally, the coordinates should be between 0 and the prime p defining the curve's field. This guarantees the public key is valid.

Precompiled Contract Specification:

The proposed precompiled contract, named P256VERIFY, allows for signature verification on the "secp256r1" (or P-256) elliptic curve. The specification provides details on the expected input and output for this precompiled contract:

• Input data: 160 bytes of data including:

  • 32 bytes of the signed data hash: This is the hash of the message or data that was signed.

  • 32 bytes of the r component of the signature: r is one component of the ECDSA signature.

  • 32 bytes of the s component of the signature: s is the other component of the ECDSA signature.

  • 32 bytes of the x coordinate of the public key: The x value of the public key's coordinates.

  • 32 bytes of the y coordinate of the public key: The y value of the public key's coordinates.

• Output data: 32 bytes of result data and error

  • Depending on the outcome of the verification process, the precompiled contract will output:

    • Success: If the signature verification is successful, it will return a 32-byte value of 1.

    • Error: If there's an error in the verification, the return might be a different value or the call might revert. The exact nature of error handling would depend on the contract's implementation details, which aren't specified in the provided section.

The idea behind this precompiled contract is to offer efficient, native support for "secp256r1" elliptic curve operations on the Ethereum platform without requiring extensive gas costs that would be incurred if implemented in standard smart contract code.