addressed some comments from Brennan

vortexor/Readme.md

@@ -37,7 +37,10 @@ Admin RPC           |  | Management     |      |                       |    |
 
 
 The Vorexor is a new executable which can be deployed on to different nodes from
-the core Agave validator. It has the following major components:
+the core Agave validator. It can also be deployed onto the same node as the core
+validator if the node has enough performance bandwidth.
+
+It has the following major components:
 
 1. The TPU Streamer -- this is built from the existing QUIC based TPU streamer
 2. The SigVerify/Dedup -- this is built/refactored from the existing SigVerify
@@ -84,11 +87,27 @@ to serve a validator to make the solution more scalable -- see blow.
                                  |
                               Validator
 
+
+When the validator is in the 'Paired' mode which it is either getting active
+transactions from the corresponding vortexor or receiving heartbeat messages,
+the validator solely receive TPU transactions from the vorexor alone as it only
+publishes the TPU address via gossip. Further, the regular TPU and TPU forward
+services in the validator will be put into the disabled mode for security and
+performance reasons.
+
+It is the presumption of this design that there is a trust between the vortexor
+and the validator. The trust can be achieved either by placing them into the
+same private network, using firewall rules plus TLS verification. When using
+QUIC on as transport for the VerifiedPacketReceiver on the validator, the
+validator can still set the QOS against the vortexor. And it is expected the
+validator will grant much higher bandwidth to the vortexor compared with regular
+TPU clients in a regular validator's TPU configurations.
+
 Deployment Considerations
 The vortexor while making the validator more scalable in handling transactions,
 does have its drawbacks:
 1. It increases the deployment complexity. By default, for validators which
-do not use vortexors, there is no deploument impact and functional/performance
+do not use vortexors, there is no deployment impact and functional/performance
 impacts. For validators using vortexors, it requires addtional deployment task
 to deploy the vortexor. For performance considerations, it is most likely the
 vortexor will be running in a seperate node from its pairing validator. To
@@ -98,7 +117,7 @@ on the validator to work with the vortexor. There will be clear public
 documentation how to run a vortexor and to pair a validator with it. There
 will be auto fallback mechanism built-in that in the case of conneciton breakage
 between the vortexor and the validator, the validator auto fallback to its
-built-in streamer. In addition, the valdator and the vortexor will support the
+built-in streamer. In addition, the validator and the vortexor will support the
 additional admin RPC to query the vortexor pairing states and mange pairing
 relationship.
 2. There is an extra hop from the original clients sending the transaction to
@@ -121,3 +140,18 @@ The solutions will be compatibile with jito-relayers in that it should not
 impact validators already using jito validator and relayers. Also, we will keep
 the arguments of vortexor CLI close to jito-relayer's CLI as possible to reduce
 surprises for validators migrating to using vortexor from the jito-relayer.
+5. The vortexor's networking setup. In the simplest format, The vortexor's
+TPU and TPU forward port might be directly accessible to the internet. Or it
+might be put behind the load balancer for security and performance.
+The vortexor is encouraged to communicate with the validator using a private
+network for performance and security considerations.
+
+Uprade Considerations
+It is up to the operators to decide if to adopt vortexors. Operators can either
+use the vortexor or not use it without concerns if the rest of the network's
+decision as the vorexor itself does not change the protocol of the network. When
+upgrading an existing validator to use the vortexor, the operator can simpily
+update the validator's CLI to specify the vortexor's TPU address and specify the
+verified packet receiver's network address. The vortexor can be started with
+the pairing core validator's verified packet receiver address. These can also be
+achieved by the respective Admin RPC on both of the valdiator and the vortexor.