📄Rationale

• Signature Components:

  • Elliptic Curve signatures typically consist of the components $�v$, $�r$, and $�s$.

  • The $�v$ component can be used for public key recovery. However, many applications do not generate the $�v$ component, leading to ambiguities in the outcome.

  • Signature verification can be done just with the $�r$ and $�s$ components.

  • Hence, for clarity and better compatibility, this proposal suggests using verification instead of recovery.

• Choosing r-s and x-y for Input Data:

  • The $�r$ and $�s$ components of the signature, as well as the $�x$ and $�y$ coordinates of the public key, are directly involved in the mathematical computations of signing and verification. Therefore, using these as the input data format is the most direct and logical choice.

  • Each of these components/coordinates is represented using 32 bytes.

• Choice of Precompiled Address:

  • The address 0x19 was chosen for this precompiled contract because it is the next available slot in the set of addresses reserved for precompiled contracts.

• Gas Cost Determination:

  • The gas cost for executing a contract is determined based on the computational resources required.

  • The performance of the proposed P256VERIFY is compared to the existing ECRECOVER (which operates on the "secp256k1" curve and is available at the 0x01 address in the EVM).

  • It was found that the "secp256r1" signature verification using P256VERIFY is about 15% slower than the "secp256k1" signature recovery using ECRECOVER.

  • By this comparison, a gas cost of 3450 was proposed for P256VERIFY. This ensures that the gas-per-operation values of both precompiled contracts are in the same ballpark.

In essence, the rationale section provides the justifications and thought processes behind various design choices and parameters associated with the precompiled contract proposal. It ensures that the design is logical, efficient, and is in alignment with existing Ethereum standards and practices.