Split BlockStreamService in Publisher and Subscriber

[AlfredoG87]

this suggestion came from @nathanklick via a side note while discussing some other subjects with @mattp-swirldslabs

• Currently we are exposing the GRPC webserver with the protobuf API definition on port 8080 (configurable)

• However the service BlockStreamService contains 2 methods: (see here)

  • publishBlockStream
  • subscribeBlockStream

• Both methods are intended to be consumed by completely different actors:

  • Consensus Nodes for publishBlockStream
  • Mirror Nodes, Other BlockNodes and others subscribeBlockStream

• The argument is that MN, other BNs and in general subscribers should NOT be able to see the publish method.

Question: Should we separate the BlockStreamService in 2?

• BlockStreamServiceSubscribe
• BlockStreamServicePublish

So we can have 2 separate web servers on the block-node.
Publish Methods: 8080 (current default port, but we can change it in the future)
Consumer Methods: 9090 (port is used only as an example)

Notes:
I don't want to advocate for this other alternative, but in the sake of completeness I believe that we can also expose the same service on both ports, and return a not allowed exception when trying to publish (assuming that is the port for consumers)

The publishers should be able to see both methods of the service, or all the services in case we split them, the limitation should only apply to consumers, so they are not capable of publishing.

For the whole API Spec, see here the protobuf definition

[jsync-swirlds]

A few thoughts:

1. We probably should not try to categorize consumers and publishers quite so broadly.
   While some block nodes may limit API access, not all block nodes should,
   or will, do so.
   • Most likely, only "core" block nodes will necessarily limit access to the
     "publish" API to select sources; many, perhaps most, other block nodes may be
     expected to accept publish streams from any economical source.
2. We should expect all Block Node services to be protected behind a proper firewall, which
   implies stateful inspection, possibly TLS termination, and the availability of full
   layer-7 routing.
   • This implies that separating by port adds no additional security, and only makes both
     client and server implementation more complex.
3. There is no requirement that any services be on different ports from any other services.
   Even if we split the BlockStreamService into a different service for each method, I would
   expect most deployments to run both services (and all other services) on a single port.
   • It's not a simple matter to split services to different ports. Most frameworks
     basically assume a single port for the entire server (Consensus node uses a single
     port for the entire gRPC server, for instance). Deploying multiple ports, as a practical
     matter, may mean creating separate servers (which may all be in one process), which adds
     quite a bit of complexity.

Basically, we must, in my opinion, implement authentication and authorization (probably
via OAuth2) on all services, and also configure proper least-access firewall rules. With
those in place, it seems, to me, to be needless added work and complexity to also require
closely related API methods to be in separate service definitions and run on different
TCP ports.

[jasperpotts]

I agree it seems like splitting ports does not seem the right trade off. There are other ways we should handle security.