3

I have seen in ethers.js documentation that there is a compressed and uncompressed public key [1] of an Ethereum keypair. Is this compressed public key used only by ethers.js or is it a common algorithm used by many libs? What algorithm is used in this compression?

See below part of Ethersjs documentation (to create a Derivation) [1].

// Public Key (compressed) computeAddress("0x0376698beebe8ee5c74d8cc50ab84ac301ee8f10af6f28d0ffd6adf4d6d3b9b762"); // '0x0Ac1dF02185025F65202660F8167210A80dD5086'

// Public Key (uncompressed) computeAddress(" 0x0476698beebe8ee5c74d8cc50ab84ac301ee8f10af6f28d0ffd6adf4d6d3b9b762d46ca56d3dad2ce13213a6f42278dabbb53259f2d92681ea6a0b98197a719be3"); // '0x0Ac1dF02185025F65202660F8167210A80dD5086'

[1] https://docs.ethers.io/v5/api/utils/address/

1 Answer 1

4

A compressed and an uncompressed public keys are coming far from the Elliptic Curve specifics. Let me try to explain you!

For finding public keys from private keys, the Ethereum protocol uses the same elliptic curve as the Bitcoin, that is Secp256k1. You can see this curve over the space of real numbers on the picture I've provided. Secp256k1 elliptic curve

The equation used is y^2 = x^3 + 3, so for one x, there will be 2 corresponding y coordinates as you can see also on the image (y1 < 0, y2 > 0).

So, there will be two pairs (x, y1) and (x, y2) as public keys. Positive pair is chosen and we've got an uncompressed public key as a concatenation of x and y2.

This format was used earlier by wallets, but as the blockchain started to grow there was a need to compress a public key. That's why it was decided to create a compressed format for a public key that would use two times less space in memory by removing the y coordinate (because it can be calculated from the x coordinate by passing it to the y^2 = x^3 + 3 equation). So now there is only x coordinate as a public key plus a prefix that defines whether the y should be negative or positive. If you look closely at your compressed and uncompressed public keys you can spot that actually, they start with the prefix 03 (for negative y compressed public key) and 04 (for uncompressed public key). But apart from that, the compressed one is the start of the uncompressed.

Now wallets try to use compressed public keys mostly but also they save the backward compatibility with older wallets that use uncompressed ones.

You can read about it in more detail here. Although this is a Bitcoin-related book, this section of it should be relevant for Ethereum keys too!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.