Exploring the Current Client Protocol Architecture about prysm

[terencechain]

Great read! it definitely opened my eyes. We should turn your write up into a Medium article to benefit broader audiences.

Take Notary as an example, do we think the following is the right path?

makeNotaryNode() gets notary config by calling makeConfigNotaryNode() and registers notary services by calling registerNotaryService(). Then makeNotaryNode() starts notary node via startNotaryNode()
Within startNotaryNode()we iterates each notary services and start(). Notary should implement the Service interface under service.go. While creation of the notaryEthereum service instance should kick off go routines such as downloader, fetcher.. etc

[rauljordan]

I'm not a fan of the complicated config setups that are spread across multiple files, but I'm a fan of having a bunch of services that implement a certain interface be attached to our notary client with each of them having a .Start() func. I don't think we should copy exactly what they did, but instead trim it down as much as possible and keep the good parts that leverage concurrency.

[rauljordan]

Hey all,

So thinking more about this as I transition into creating a PR for #109, here is a proposal I would like to make for our sharding clients moving forward. As our code base grows, it's important to think about how we can best leverage concurrency, event management, and simple configuration options that don't cause any headaches to those reading our work. There are elements of the light node design that I'd like to incorporate into our system for spinning up notary/proposer clients. Here are the ideas:

Design

The key idea is that our sharding entry point will spin up a ShardingClient struct, which is analogous to geth spinning up an instance of a Node.

• There is a key command line flag called ClientType that specifies if the client will be a Notary or Proposer instead
• The main entry point sets up a ShardingClient instance
  • attaches configuration options from cli flags
  • contains a utility function that registers a ShardingService: either Notary or Proposer
  • starts each of these services in a concurrency-safe fashion
• Notary and Proposer instances implement a ShardingService interface that defines common methods to both, including, but not limited to:

  type Service interface {

    // Protocols retrieves the P2P protocols the service wishes to start.
    Protocols() []p2p.Protocol
    
    // APIs retrieves the list of RPC descriptors the service provides
    APIs() []rpc.API

    // Start is called after all services have been constructed and the networking
    // layer was also initialized to spawn any goroutines required by the service.
    Start(server *p2p.Server) error

    // Stop terminates all goroutines belonging to the service, blocking until they
    // are all terminated.
    Stop() error
  }

The idea of attaching services this way to the sharding client allows service life-cycle management to be the responsibility of the sharding client itself. Moreover, every single goroutine pertaining to a service can be spun up and contained within its .Start() method.

• The .Start() function will open a local shardchaindb file storage, and spin up notaries and proposers' respective p2p ServerPools and ProtocolManager's .Start() methods
  • ServerPool kickstarts an event loop that handles peer discovery, new connections, and disconnections from peers
  • ProtocolManager is struct that handles notaries and proposers' respective event loops (i.e. interacting with the SMC, the voting process, etc.), their corresponding serverPools, their chaindb, txpools, and message requests/responses from other peers.

A ProtocolManager interface allows for a well-defined set of responsibilities and goroutines executed by notaries and proposers.

The lifecycle of notaries and proposers in the p2p network can be handled via a callback as in the les package that deals with the handshake between peers, and an eternal loop of responding to incoming messages via the ProtocolManager's handleMsg functionality.

Clients React to Each Other Via the ProtocoManager's handleMsg Function

There is a fixed set of messages sharding clients can respond to and send. We can follow the same approach as done in the les package's ProtocolManager.handleMsg function to do this.

Overall, I suggest we keep configurations in a single place, without many dependencies across files, and we document everything extensively. Let me know your thoughts.

@prestonvanloon @terenc3t @nisdas @enriquefynn @Magicking

[terencechain]

Looks good. In regard to how clients interact with each other, check out this LES flow control writeup: https://github.com/zsfelfoldi/go-ethereum/wiki/Client-Side-Flow-Control-model-for-the-LES-protocol

[rosulucian]

Raul, do you know of any other similar docs that could help a new developer peek inside the geth architecture& design?
Great job on this one, though! It really helped me get a broad picture of the geth design (not limited to the light client)