PeerId: Why protobuf wrapped as multihash? #3079
-
I was confused that a 32 byte Ed25519 pubkey ends up being 38 byte So I expected After a few hours of digging through the sources I figured out that PeerId is a multihash of type Is there any reason why libp2p mixes multihash and protobuf? Both protocols - multihash and protobuf - kind of achieve the same thing, so only one of them would be sufficient to encode a self-describing public key. I would argue, why not only use multihash and get rid of the additional protobuf encoding? Multihash has the types of public keys libp2p uses right now already defined:
Using multihash-only for the Any thoughts? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
In principle, you are right. There is room for optimisation. This would have to be discussed on a spec level (see https://github.com/libp2p/specs). Especially Personally, I am not a huge fan of protobuf but I see the benefit when it comes to describing protocol messages. For simpler data types like We'd also have to figure out how this interacts with https://github.com/libp2p/specs/blob/master/RFC/0001-text-peerid-cid.md which we are yet to support in |
Beta Was this translation helpful? Give feedback.
In principle, you are right. There is room for optimisation.
This would have to be discussed on a spec level (see https://github.com/libp2p/specs).
Especially
go-libp2p
has many deployments outside of our control so any change would have to be rolled out carefully and in a backwards-compatible way.Personally, I am not a huge fan of protobuf but I see the benefit when it comes to describing protocol messages. For simpler data types like
PeerId
, I'd be in favor of trying to remove it.We'd also have to figure out how this interacts with https://github.com/libp2p/specs/blob/master/RFC/0001-text-peerid-cid.md which we are yet to support in
rust-libp2p
. See #2259.