owned this note   changed 7 years ago  
Linked with GitHub

Eth 2.0 libp2p Daemon Workshop

tags: 2018_prague_working_group libp2p networking

Overview

This document summarises some of the ideas that were discussed in the Ethereum 2.0 workshop examining the libp2p daemon. The workshop was held on 29th of October 2018 in Prague.

This event was preceeded by the following document, which describes the purpose of the meeting: https://notes.ethereum.org/9v_oAYZcSpO0I_pogfHkPA

Attendees

(if you were there, please check your name)

  • [Lead] Raul (libp2p)

  • Alexey Akhunov

  • Zak Cole

  • Eugene Kabanov (Nimbus/Status)

  • Kevin Chia

  • Jannik Luhn

  • Nicholas Lin

  • Chih-Cheng Liang

  • jonny rhea

  • Steven Schroeder

  • joseph delong

  • Luke Anderson (Lighthouse/Sigma Prime)

  • Priom (ChainSafe/Lodestar)

  • Paweł Bylica

  • Mike Goelzer (libp2p) - partial attendance

Objectives

Identify design goals and requirements for libp2p daemon.

Meeting Agenda

To begin the session, a list of outcomes was created, as guided by participants.
(photo of outcome list)

Actual daemon

An overview of the daemon mechanics was provided by Raul (lead), accompanied by this overview diagram.
The overview was summarized (illegibly) by Luke in this diagram.

  • The daemon is implemented in Go.
  • Currently one daemon spawns for each process that's using it
    • In future: a single daemon should support multiple processes (multi-tenant)
  • Currently, a configuration file is used to configure options (such as DHT lookup features)
    • In future: This will change once the daemon is multi-tenant.
  • There exists "native implementations", which are integrated into the software that uses them (e.g. Rust). The daemon is basically a "native implementation" written in Go, which has it's features exposed.
  • In future: The goal of libp2p is to be integrated into the Linux kernel
    • The speed increase of having libp2p integrated into the kernel, with features like pubsub, will be necessary to achieve a decentralized status-quo.

Windows

  • Need to implement "named pipes" in Windows.
    • While Windows IO does support UNIX sockets now, the support is limited.

D.H.T.

  • "Get Closest Peers" is a stream
    • This could hijack the connection - a potential for corrupting data if it is used twice.
  • Other DHT commands are supported, including "DHT symlinks"
  • DHT is a feature of libp2p and is not fundamental to the structure.

PubSub

  • Application needs an endpoint for each subscribed topic
  • Messages are validated via a socket, before the message is relayed
    • Validation happens even if a node is forwarding a message that it is not explicitly subscribed to ("grafted").

Implementation holes

A discussion was had regarding known missing features and shortcomings of the implementation.

  • Insufficient protocol versioning

  • Documentation is lacking

  • Package management is lacking

  • The code is currently quite hard to follow

  • Implementation was created before specification

    • libp2p is moving towards a spec-first approach, but takes time
    • Current specs/docs are not up to scratch
    • Reason is that code was factored out of IPFS (hence using Golang)
      • Parity then re-implemented in Rust, but have only focused on a subset of features necessary for their client, and have not implemented the daemon interface (hence does not run stand-alone)

  • Better governance of the protocol is needed

Adversarial environments

  • Miner/Validator locations can be discovered

    • This allows an attacker to determine network connectivity, divide the network, and potentially isolate miners/validators
    • In proof-of-stake, it may be easier to hide the network location of the validator; more easily than in proof-of-work.

  • libp2p has looked into peer reputation systems, but that would require a "social overlay" - too much complexity for now.

  • Would be good to have a "traffic shaper" for Kademlia, rather than just random connections.

  • Concerning an Eclipse Attack on an Ethereum node using Kademlia

    • The node needs to be able to detect the attack somehow
    • P2P connectivity could take two forms:
      • Structured/Deterministic:
        This is more efficient, but more prone to such attacks.
      • Unstructured:
        This is less prone to attacks (as the peer layout is not predictable) but the network is less efficient.

  • It may be possible to incorporate built-in "Circuit Relays", similar to that of TOR.

WASM

  • Should libp2p be implemented in WASM?
    • WASM is only computation - no files etc.
    • System calls would need to be emulated and would have to "escape" to do file handling etc. via "exported"/"imported" functions.
      • This would allow existing software to be compiled into WASM
  • This would be a "dream"
    • Allowing one implementation compiling to WASM rather than a number of native implementations
  • Should there be a libp2p WASM working group?
    • There are already libp2p communities around each implementation language. They will not want to drop what they've done and move to WASM as this will cause delays.
  • It is better to have diversity, and to not have a single implementation

Shared memory

  • Unix sockets are much slower than shared memory (SHM)
  • A super-fast communication link will create "back pressure"
    • This would require building signalling into the application, to notify of the back pressure.
    • This signalling comes natively from socket blocking.
    • The bottleneck is writing to the network, so having a super-fast interface would not help a lot.
  • Maybe we could have different "classes" of traffic
    • SHM could be used for a kind of ring buffer
    • This might be useful for:
      • List of connected peers
      • WebRTC?

Outstanding Questions

What are some of the questions left-over from the discussion?

Select a repo