Validator node - Central node connection migrate from web socket to pub / sub.

[bartossh]

Websocket connection consumes resources per connection and is blocking.
The internal pub/sub queue for validators to pull messages from central nodes will be a much simpler solution.

• The validators must know about the new block to validate it - the central node can place it on the pub/sub queue (single producer multiple consumers) in fire and forget mode (total async non-blocking and consuming only one network connection.
• The validator must know about the transaction being sent to the receiver or being signed by the receiver - the same pub/sub principal applies as the one with a new block.

What are the drawbacks:

• Another service is required.
• Single entity managing the traffic - needs redundancy and dedicated resources, probably a fast server or cluster of servers.
• More expensive on small systems.
• Requires a bigger refactor.
• Difficult to reverse back to the old protocol.
• Requires introduction of a new authentication and authorization of the validator node.

What are the benefits:

• Central and validator nodes save on connections (I/O) calls. Single connection per node.
• Noticeable performance gain, complexity O = 1, when current complexity O = n. Less RAM and CPU consumption. Entity is processed once for all the validators by the central node.
• Asynchronous or/and managed by the dedicated process.
• Simplified, easy to maintain.
• Recconecton is simplified and easy to introduce.
• Single place of failure - easier to recover the system.
• Much less network bandwidth is required, which will allow the operating system to spend less time on IO calls and will save traffic on the clusters.
• Saves money on a large-scale system.
• Can open the possibility for performant sharing of other resources.
• Removes the requirement for central nodes to track other central nodes' registration addresses and validator nodes' addresses.
• There is no involvement of the central node in the process of registering the validator.

[dmatusiewicz-consult-red]

I agree that validators might be hard to scale. Would it be possible for someone to implement their own validators that would consume the queue?

• I can imagine that this would be a fan-out model - right?
• For fast prototype i would consider NATS.io - i have experience with it and i would be able to help with the implementation.

[bartossh]

@dmatusiewicz-consult-red it seems that the fan-out model is the way to go.
Nats.io sounds great (keeping low resource requirements and performant systems - Go stack)

And Yes, implementing their own validators to consume the queue is feasible for anyone who owns a wallet and or token (tbd).