Public Keys vs Addresses on ETH2 Beacon Chain

Question

1. Why do we reference ETH2 validators by their public key while in ETH1 we use addresses for that?
2. After the merge, can we expect that we also use addresses for validators?
3. Why are public keys in ETH1 128 chars long (e.g. 21d5fd65a7597237050a94e3669d38d8a060d87627a956db18a1693fd9fe1bc0a39fb4b0eac47ebd6c50f83d9c4a04e8d039c88bc4db6a547d1b7e111d0853b1 taken from https://asecuritysite.com/encryption/ethadd) while ETH2 are only 96 (0x833bf8a530768ca6b6afa664ab11adefd5d445be13e7e27a4889850dd8484e0ed957a0d2a86f7625b64936fabe2572fc taken from beaconcha.in) chars long?

Answer 1

1. Eth1 addresses are just (truncated) hashes of their public keys. We could also do that with validators, but it doesn't gain anything and would actually make debugging harder since validators are stored in the beacon state with their full public keys. Unlike in Eth1, we can't recover a public key from a signature (using ECRecover), so we need to store it as-is in protocol.

2. A validator's public key is not an address. It is never used to send transactions to a validator, only to reference the validator in-protocol. So it is convenient to keep the 48 bytes format as-is. This will not change after the Merge.

3. The Eth1 and Eth2 beacon chain protocols use two totally different signing schemes. Eth1 transactions use ECDSA with the secp256k1 elliptic curve. Eth2 protocol messages use BLS signatures with the BLS12-381 curve. BLS12-381 public keys (as we implement them) are 96 bytes long in full form, and 48 bytes long if compressed (when you store only the X coordinate). Eth2 uses the compressed form to serialise public keys, so it's 48 bytes long as per the one from beaconcha.in you show (96 hex characters).