What is secp256r1 (P256)?

Prerequisite Knowledge

In the world of cryptography, elliptic curves are widely used for generating public and private key pairs to ensure secure data encryption and digital signatures. Cryptographic algorithms based on elliptic curves achieve secure key generation and exchange through operations on points defined on the curve. Below is a visualization of a typical elliptic curve structure:

The general formula for an elliptic curve is y² = x³ + ax + b, where the parameters a and b determine the shape and characteristics of the curve. Different combinations of a and b yield different elliptic curves, and these curves may vary significantly in terms of design principles and security features. This is where the two elliptic curve standards — secp256r1 and secp256k1 — differ significantly, which is the focus of this discussion.

A Deep Dive into secp256r1 and secp256k1

Let’s start with secp256k1. This is a non-randomly constructed elliptic curve, also known as a Koblitz Curve. Its equation is y² = x³ + 7, meaning a=0, b=7. The choice of fixed parameters here serves to simplify computations and improve efficiency, while also mitigating the risk of backdoors that might arise from arbitrarily chosen random parameters. This design choice is one of the reasons Satoshi Nakamoto selected secp256k1 for Bitcoin.

In contrast, secp256r1 is a randomly generated elliptic curve, where "r" denotes "random." Its defining formula is y² = x³ + ax + b, with a=0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc and b=0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b. While this parameter selection makes P256 slightly less efficient in calculations than secp256k1, its greater mathematical complexity theoretically offers enhanced security (though this is limited).

Why These Two Parameters?

In these parameters, a is actually -3, but in the finite field Fp, negative numbers are typically represented by their corresponding positive values modulo the prime. Thus, 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc represents a=−3. This is a concise and widely used parameter that even helps optimize the performance of elliptic curve point calculations, making it a common choice in many elliptic curve standards. On the other hand, b is a carefully chosen 256-bit constant, ensuring the curve meets the non-singularity condition $4a^3+27b^2 \neq 0$. This limited disclosure of information and the lack of a detailed generation process leads to suspicions of potential backdoors, resulting in reluctance among blockchain projects to adopt it. (Of course, such concerns are not directly evidenced.)

Why Do We Need P256?

Given the potential risks associated with P256, why should we still consider introducing this cryptographic curve into Mantle? The answer is simple: it’s a remedy for the poor user experience (UX) that currently plagues blockchain ecosystems.

At present, secp256k1 is the dominant elliptic curve used by blockchain protocols like Bitcoin and Ethereum. While it has proven effective in the cryptocurrency domain, it has not been widely adopted across the broader internet and mobile ecosystems. Modern browsers, operating systems, and hardware devices generally lack support for secp256k1, which creates significant complexity for blockchain users when operating across devices and platforms. For instance, users are often required to install additional cryptocurrency wallet applications to manage their private keys. These wallets typically rely on manual processes, such as saving mnemonic phrases or private keys, which is cumbersome and unintuitive for the average user. This friction has become a major barrier to blockchain adoption.

In contrast, secp256r1 (also known as P256) is one of the most widely supported elliptic curves in the internet and mobile ecosystems. Its applications are extensive, particularly in the WebAuthn standard. WebAuthn is a passwordless authentication protocol based on public-key cryptography, supported by major browsers (e.g., Google Chrome, Safari, and Firefox) and platforms (e.g., Windows, macOS, and Android). These implementations typically rely on the secp256r1 curve. Additionally, in systems like Apple iCloud Keychain and Android Keystore, private keys created by users can be directly stored in the secure enclave of their devices and used for signing operations with secp256r1. This hardware-level integration eliminates the need for users to remember complex passwords or keys, as the device itself acts as a hardware wallet.

For users, adopting secp256r1 translates to a more seamless and intuitive experience. They no longer need to manually save private keys or mnemonic phrases. Instead, transactions can be signed directly using the device’s built-in security module, often with the help of familiar biometric features like fingerprint or facial recognition. For developers, supporting secp256r1 expands the potential user base for decentralized applications (dApps) and ensures better compatibility with existing hardware, accelerating blockchain’s journey toward mainstream adoption.

In essence, the introduction of secp256r1 strikes a balance between security and user experience, making blockchain technology more accessible to everyday users.

How Do We Implement P256?

High-Level Architecture

The diagram above illustrates a scenario in which a DEX swap is completed using Face ID after implementing P256. The workflow generally unfolds as follows:

1. Key Pair Generation: The user first generates a P256 key pair through the Passkeys API. The private key is securely stored in the Apple Secure Enclave, while the public key is recorded in the application or sent to the associated account on the Mantle network.
2. Initiating a Transaction: When the user decides to initiate a transaction within the application, they construct a swap transaction. At this point, the application invokes Face ID for authentication.
3. Authentication and Signing: After successful Face ID authentication, the Secure Enclave signs the transaction hash, generating the signature parameters (r, s, x, y).
4. Transaction Submission: The DEX packages the transaction data, signature parameters, and public key into a transaction object and sends it to the Mantle network.
5. Block Packaging and Execution: Upon receiving the transaction, the sequencer completes block packaging and sequentially executes the transactions within the block. During this execution process, a precompiled contract is invoked to verify the P256 signature.
6. Transaction Confirmation: Once the verification is successful, the transaction is executed, and the network state is updated accordingly.

Implementation

In our implementation, we introduce a precompiled contract in op-geth to perform signature verification on the secp256r1 curve within the EVM. Below is an example of how it works:

During the verification, we input a []byte structure, which is an array of 160 bytes in length. This array contains five parameters, each 32 bytes long: the hash value of the message signature, the signature components r and s, and the x and y values of the public key.

For the verification process, we call the ecdsa's Verify function to complete the signature verification. If you are interested in the detailed operations of Verify, please refer to this. Ultimately, if the signature verification is successful, it returns []byte1; otherwise, it returns a nil value.

Additionally, in our implementation, we set the gas cost for verification at 3450, which aligns with the existing ECRECOVER (the precompiled contract for secp256k1) cost of 3000, ensuring consistency in terms of magnitude. The address for the precompiled contract is set to 0x0000000000000000000000000000000000000100.

The Value of P256 for the Mantle Ecosystem

The introduction of P256 as a precompiled contract brings profound implications for the Mantle ecosystem.

First and foremost, it significantly enhances the integration of Account Abstraction proposals. Through the P256 precompiled contract, Mantle can better implement proposals such as EIP-4337 and ERC-7702, offering developers greater flexibility in signature abstraction. This integration enables Mantle’s smart wallets to natively support hardware-based signatures (e.g., Apple Secure Enclave and Android Keystore), greatly improving both security and compatibility. Users can leverage modern hardware modules to manage their keys and signatures without relying on third-party wallet apps or complex private key management, making the ecosystem far more user-friendly.

Second, P256 provides immense benefits for traditional DeFi users within the Mantle ecosystem. Previously, DeFi users had to manually manage complicated mnemonic phrases and private keys, which was not only cumbersome but also prone to errors. By contrast, P256-supported hardware signatures allow users to complete transaction signing directly using devices such as smartphones. This seamless interaction significantly reduces the likelihood of user error while offering a more intuitive and accessible user experience.

Additionally, the introduction of P256 through a precompiled contract drastically reduces the cost of signature verification. This cost efficiency is particularly advantageous for high-frequency trading and complex contract interactions within DeFi applications, providing a tangible competitive edge for these use cases.

Finally, Mantle’s role extends beyond being a standalone blockchain network—it also serves as a testing ground to validate the demand and potential of P256 in real-world scenarios. By introducing P256, Mantle can provide valuable data and insights to the broader EVM ecosystem. This effort not only attracts a wider user base but also drives innovation across the blockchain industry. If P256 proves its value within the Mantle ecosystem, it will likely accelerate its adoption on the Ethereum mainnet, setting the stage for broader implementation across the blockchain space.

Summary

By integrating P256, Mantle bridges the gap between blockchain technology and mainstream hardware ecosystems. This not only simplifies user interactions but also sets the stage for broader adoption. If successful, Mantle’s P256 implementation could pave the way for its future integration into the Ethereum mainnet and beyond.