search

ethereum / consensus-specs

Ethereum Proof-of-Stake Consensus Specifications
Creative Commons Zero v1.0 Universal
3.51k stars 953 forks source link

Decide on address format #2148

Open paulmillr opened 3 years ago

paulmillr commented 3 years ago

I think we should start discussions on eth2 address format.

The hash function seems to be SHA2-256 nowadays. Should bech32 be used? How long should the addr be?

vbuterin commented 3 years ago

Given that eth2 addresses are just eth1 addresses (as the existing eth1 state would be migrated onto eth2), would this be a new serialization scheme for existing addresses? Or would the goal be to expand from 20 bytes to something longer (26 bytes?) for safety? If we want to do the latter, we should probably start talking to the eth1 team asap to do the switch at the same time as the hex -> bin tree conversion so that we can make all addresses longer (prefix them with zeroes or whatever) instead of permanently needing to support multiple lengths.

paulmillr commented 3 years ago

So, we'll have two systems:

  1. Eth1 shard on eth2 that would keep using secp256k1
  2. Other shards, where only bls12-381 is used to sign transactions

The scheme would need to be able to create addresses for both cases.

Seems like it would be great to be able to send to eth1 addresses. Or, we can move all addresses into new scheme.

I see three issues with current approach:

  1. Checksum is optional
  2. Case-sensitivity
  3. There is no prefix to distinguish eth addresses from other projects

Bech32 is case-insensitive, uses prefix, and is checksummed.

The address could look like:

eth1qhvmnmagepmt6wuz0mnyf63qux3rxkk30fgvzv9

paulmillr commented 3 years ago

If we're going to use one address type for everything, how would we handle collisions? E.g. different keys on bls381/secp256 that point to one address

ralexstokes commented 3 years ago

So, we'll have two systems:

  1. Eth1 shard on eth2 that would keep using secp256k1
  2. Other shards, where only bls12-381 is used to sign transactions

The scheme would need to be able to create addresses for both cases.

Seems like it would be great to be able to send to eth1 addresses. Or, we can move all addresses into new scheme.

if i'm understanding you correctly, it is worth noting:

while the details are still up in the air, i think there will generally be special mechanisms to go from "inside the EVM" (i.e. eth1 today, secp256k1 crypto) to "outside the EVM", e.g. moving ETH from a validator entity in the system to a user account. if we move ahead w/ the "rollup centric" vision of the world (https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698), we may not even have a concept of user-level transactions on the shards themselves as these messages would be processed in the one "computation shard" / inside the EVM (with special access to shard data, much like the BLOCKHASH opcode today). so we can pretty cleanly keep secp256k1 cryptography where it is today and still use BLS cryptography on the beacon chain. and in this case, we would not need to worry about interoperating between the two.

I see three issues with current approach:

  1. Checksum is optional
  2. Case-sensitivity
  3. There is no prefix to distinguish eth addresses from other projects

sidenote: we have effectively assumed the 0x prefix as an ethereum-specific thing

Bech32 is case-insensitive, uses prefix, and is checksummed.

The address could look like:

eth1qhvmnmagepmt6wuz0mnyf63qux3rxkk30fgvzv9

alongside the above, we can definitely have a discussion about enhancing safety/usability of eth1's address format although there are likely better forums for that, like ethresear.ch or fellowship of ethereum magicians :)