feat!: Address agnostic p2p#5176
Conversation
91e7ea6 to
37209a0
Compare
|
Update:
|
37209a0 to
bcd2b69
Compare
Signed-off-by: Dmitry Murzin <diralik@yandex.ru>
Signed-off-by: Dmitry Murzin <diralik@yandex.ru>
Signed-off-by: Dmitry Murzin <diralik@yandex.ru>
Signed-off-by: Dmitry Murzin <diralik@yandex.ru>
Signed-off-by: Dmitry Murzin <diralik@yandex.ru>
Signed-off-by: Dmitry Murzin <diralik@yandex.ru>
Signed-off-by: Dmitry Murzin <diralik@yandex.ru>
Signed-off-by: Dmitry Murzin <diralik@yandex.ru>
bcd2b69 to
1194e61
Compare
| /// Peers received via gossiping from other peers | ||
| /// First-level key corresponds to `SocketAddr` | ||
| /// Second-level key - peer from which such `SocketAddr` was received | ||
| gossip_peers: BTreeMap<PeerId, BTreeMap<PeerId, SocketAddr>>, |
There was a problem hiding this comment.
I think we need some eviction policy. This can be done separately
There was a problem hiding this comment.
Do you mean to periodically drop entries which were received long time ago?
Currently we have eviction based on topology
There was a problem hiding this comment.
Currently we have eviction based on topology
I see, I think then it's ok. Can a malicious actor overwhelm other peer's gossip handle?
There was a problem hiding this comment.
Can a malicious actor overwhelm other peer's gossip handle?
Single malicious actor can't, since we choose address using majority rule
There was a problem hiding this comment.
I get that, but a single malicious actor could send lots of different false addresses, couldn't it?
There was a problem hiding this comment.
Only last entry is kept in the map.
E.g. consider we have three good peers PeerA, PeerB and PeerC and one malicious PeerD. Let's observe how PeerA will determine address of some PeerX. PeerB and PeerC will send correct address GoodPeerX.com:8000 to PeerA, and PeerD will send Bad1PeerX.com:8000. So gossip_peers for PeerA will look like this:
{
"PeerX": {
"PeerB": "GoodPeerX.com:8000",
"PeerC": "GoodPeerX.com:8000",
"PeerD": "Bad1PeerX.com:8000"
}
}
Based on majority rule, PeerA will use GoodPeerX.com:8000 as address for PeerX. Next, consider PeerD again sends another bad address Bad2PeerX.com:8000 to PeerA. Now map will change to:
{
"PeerX": {
"PeerB": "GoodPeerX.com:8000",
"PeerC": "GoodPeerX.com:8000",
"PeerD": "Bad2PeerX.com:8000"
}
}
Again using majority rule, GoodPeerX.com:8000 will be selected.
Context
Fixes #5117
How things currently work:
sumeragi.trusted_peersconfig parameter with addresses of initial peersSolution
Planned changes:
network.addressUse case: Peer changes address
Use case: New peer added
iroha1:8000andiroha2:8000iroha3:8000sumeragi.trusted_peers- only peer Anetwork.public_address-iroha3:80009.9.9.9:52143(52143is some random port chosen by C for outcoming connection, and9.9.9.9is some IP address, e.g. local IP address in kubernetes cluster)iroha3:8000) to AMigration Guide
network.public_addressin the config, orP2P_PUBLIC_ADDRESSenv var). This parameter should contain external address of the peer used for p2p (as seen by other peers)genesis.json— changedtopology:Before:
After:
Review notes
Most meaningful changes are:
crates/iroha_core/src/peers_gossiper.rs- logic related to peers gossipingcrates/iroha_p2p/src/network.rsPeersGossiperservice. (Previously peer connects to addresses of peers from topology)crates/iroha_p2p/src/peer.rs- after establishing connection, peer now sends itspublic_addresscrates/iroha_data_model/src/peer.rs- moved address fromPeerIdtoPeerOther changes are mostly related to
Peer/PeerIdTODO:
multiple_networks)Checklist
CONTRIBUTING.md.