[RFC] libp2p for Coda networking #2211
Conversation
rfcs/0000-libp2p.md
Outdated
|
|
||
|
|
||
| - On the daemon side, we will use `go-libp2p`. `rust-libp2p` lacks some features (pubsub validation) that we want. | ||
| - For the transport, secio over TCP (optionally with WebSocket). secio is libp2p's custom transport security protocol. I believe the libp2p developers intend to replace secio with TLS 1.3 in the future. Transport security is not yet essential for us, but it's nice to have and will become more important once we start using relays. |
There was a problem hiding this comment.
A relay is a server that shuttles messages between two peers. Encryption is important so that the peers can get privacy guarantees for their communications. An example of when it might be needed is when two parties that are behind a symmetric NAT need an intermediate relay to establish communication. In particular, you'd need a TURN server for making this happen.
|
Just wondering, where will all the RPC server implementation code live? Will they be passed down as handlers and live in Coda_lib, like how we have it right now? Where will the RPC signatures live? |
rfcs/0000-libp2p.md
Outdated
|
|
||
| Concretely, this will be implemented by spawning a child process that speaks a simple JSON protocol. This will let us use `go-libp2p` (which seems to be the most robust libp2p implementation at the moment) without figuring out how to get Go and async working in the same process. | ||
|
|
||
| `Pubsub` will replace the `Gossip_net` functionality. Topic names will be `{genesis state hash}-{description}`: `{hash}-states`, `{hash}-transaction-pool-diffs`, `{hash}-snark-pool-diffs` . Additional topics are easy to add. The raw pubsub messages are uninterpreted bytes; it will be up to the caller to map the pipe with useful de-serialization. Topic message validation might be a problem. There's a default timeout of 150ms waiting to validate a message. We can turn it up, but incoming messages can come with their own timeout. There are some synchronous operations that can take longer than 150ms in our daemon (I think sparse ledger creation exceeds that right now, at least when ledger_depth=30). |
There was a problem hiding this comment.
Can you speak to if libp2p offers adversary protection? Kademlia for example uses a DHT to determine the topology of the network, which increases the difficulty of an adversary performing an eclipse attack.
There was a problem hiding this comment.
In their docs they claim: This DHT is modeled after kademlia with S/Kademlia modifications. From the implementation and issues, it seems they implement at least 4.4 from the S/Kademlia paper. nodeIDs are also the hashes of the peer IDs (which themselves are either public keys or hashes of public keys). This is what prevents the easiest forms of eclipse attacks. Beyond the more robust routing/lookup algorithm, I don't think there are significant sybil mitigations.
|
@johnwu93 this RFC doesn't affect that level of RPC. We can refactor |
Node identity + key managementIn libp2p, every network participant has a We need to generate and store the secret key. Does the key need to be stable? I think probably not, although unnecessary PeerID churn will hurt routing security, which depends on old nodes to prevent your routing table from filling with new, malicious peers. Where should we store the private key? Should we require users to generate the keypair manually, or do it automatically and keep it hidden? If the key is leaked, anyone can impersonate you. Beyond whatever libp2p does with it internally, do we care about libp2p identity? Right now the trust system works at the IP level. We can't switch that to work on PeerIDs, since they can be generated at will. I think we should continue to put trust at the IP level, and if one peer using an IP is dishonest, we drop the whole IP. This will interact with relaying in the future (where well-connected nodes will forward streams on behalf of poorly-connected nodes). I'm not sure exactly how yet, I haven't looked at the relaying protocol yet. |
rfcs/0000-libp2p.md
Outdated
|
|
||
| Here's a WIP signature for the new net: | ||
|
|
||
| ```ocaml |
There was a problem hiding this comment.
How does OCaml communicate with libp2p? Via FFI to Go?
There was a problem hiding this comment.
Using a simple (ad-hoc) JSON protocol over stdin/stdout of a subprocess. No FFI so we don't have to deal with any potential runtime conflicts.
|
If you decide to move forward to with this, you probably want to track. IMO I consider the issues in there to be a blocker on moving Cosmos/Tendermint to libp2p |
|
That's interesting, but the current wire protocol is completely
unencrypted, so I'm not super concerned. If we decide to implement private
transactions, we'll want to use Tor or something anyway. I suppose
encryption in the wire protocol stops your ISP/coffee shop/whatever reading
your transactions, which *is* desirable, but not important at this stage.
…On Sat, Aug 3, 2019 at 6:49 PM Zaki Manian ***@***.***> wrote:
If you decide to move forward to with this, you probably want to track.
libp2p/specs#195 <libp2p/specs#195>
IMO I consider the issues in there to be a blocker on moving
Cosmos/Tendermint to libp2p
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2211>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAPATPNDFUG6CKWPRYD553QCYYULANCNFSM4HFC2BBQ>
.
|
emberian
added
the
ready-to-merge
No description provided.