It's true, dropping the fingerprint is quite invasive and might break things. But that's why we're making plans now to make this transition as smooth as possible.
However, I don't think that we can get away by just replacing the existing 20 byte long RSA key digest with a 20 byte long hash of the new, 32 byte long ed25519 key. There are probably cryptographic reasons for that. But in addition to that, there should be a time when relays use both fingerprints in parallel so that directory authorities and other tools can build a map from old to new identities. Otherwise, relays would lose all their history only because they are switching from RSA to ed25519, and wouldn't that be sad? There might be more reasons that I'm currently not thinking of. But: I'm not making this call, I'm just thinking about the possible impact of this change and which code needs to be updated.
How about we talk more about this in Berlin together with Nick? Maybe take a look at the list I wrote and think of other code that will need work when this change actually takes place?
Certainly, sounds good! For what it's worth my concern is about the fingerprint's longstanding role as the relay identifier. Some spots off the top of my head...
* The control spec allows you to query descriptors by fingerprint or nickname. * Circuit events and most other things citing relays do so by fingerprint or fingerprint~nickname. * Atlas, Globe, and just about every tool that allows you to look up relay information does so by fingerprint. * In Stem anything related to identifying a relay does so by fingerprint.
No doubt there's many, many other things that'll break too. This is the main identifier of a relay and I'd expect mucking with it to break all the things. Hence my interest in an in-place replacement instead. ;)
Cheers! -Damian