Merge latest docs from private operator docs (#107)

* Merge latest docs from private operator docs

* Add quick navigation to the quick nav

* Update joining-the-testnet.md

* Update for latest changes

* Update architectural overview

* Update src/operators/architectural-overview.md

* Update joining-the-testnet.md

* Minor copy changes

Made some minor grammar changes, and added a caveat to the first paragraph.

* Update src/operators/architectural-overview.md

* Update src/operators/maintenance/wiping-node-state.md

* Consistent headings

* Consistent capitalization

* Nits

* Nits

src/operators/architectural-overview.md

@@ -4,27 +4,80 @@ As an operator of a Node on the Oasis Network, it is suggested that you have an
 understanding of the system architecture of the Oasis Network. Here we will
 provide a high level overview of the Oasis Network's architecture. This overview
 is used to provide enough guidance to be useful for the purposes of getting
-started as a Node Operator. For more information, see
-[our whitepaper](https://www.oasislabs.com/whitepaper).
+started as a Node Operator. Note that not all of these features are available in the Public Testnet, and their design may change in later phases. For more information on our proposed design, see
+[our research papers](https://www.oasis-protocol.org/researchpapers).
+
+## Definitions
+
+### Entity
+
+An Entity is an organization or individual with stake on the network. Each
+Entity has a private key that controls access to the wallet of the Entity. See
+[Entities and Key Management](#entities-and-key-management) for further
+information.
+
+### Node
+
+A Node is a device (VM, Bare Metal, Container, etc.) that is participating in a
+committee on the Network. Each Node has a private key that is used for signing
+operations during block production and a public key, or Node Identity, used for
+identification. See [Entities and Key Management](#entities-and-key-management)
+for further information.
+
+### Committee
+
+A Committee is a set of Nodes that are participating in the same service layer
+of the Oasis Network. Committees are described in more detail in the [Modular
+Architecture](#modular-architecture) section.
 
 ## Modular Architecture
 
 The Oasis Network uses a modular architecture similar to that of a Service
-Oriented Archiecture or a Microservices Architecture. Any given node
+Oriented Architecture or a Microservices Architecture. Any given Node
 participates in one of many different committees. These committees each have
 different responsibilities in the execution of smart contracts on the Oasis
-Network. The responsibilities of these committees can be mapped to a set of 4
+Network. The responsibilities of these committees can be mapped to a set of four
 different layers: Consensus, Compute (Confidential and Non-confidential),
 Storage, and Key Management. For a Node Operator, these layers map distinctly to
 different classes Nodes and potentially to different hardware.
 
-### Transaction Processing Diagram
+### Committee Responsibilities
+
+![Transaction Processing](./operator_images/web3_diagram_v2.png)
+
+In the figure above, we see the flow of transactions in each committee. The
+details of each committee is best described in our [research
+paper](https://www.oasis-protocol.org/researchpapers), but we provide this section here
+as a high level introduction. It should be noted that some aspects of the system
+are yet to be completed. So the testnet that you might deploy in the [Quick
+Start Guide](./quick-start.md) won't yet function as it is described here.
 
-![Transaction Processing](/operator_images/web3_diagram_v2.png)
+#### Registry
+
+Although not pictured, the Registry maintains a list of valid Entities, Nodes,
+the Committees that each Node has registered to participate, and the lifetime of
+each Node.
+
+#### Committee Scheduler
+
+While not a committee unto itself, the Committee Scheduler assigns eligible
+nodes to specific committees for some duration of epochs. The pool of Nodes to
+be scheduled are chosen from the Registry.
+
+It is possible that a Node can register for more than one committee to make
+efficient use of hardware. If, for instance, a Node registers with the
+possibility of operating as a Storage or Compute Node, the Committee Scheduler
+will assign it a single job during a given lifetime.
+
+#### Consensus Committee
+
+The Consensus Committee is the BFT consensus layer. Its primary function during
+transaction processing is to reach consensus on the final state of the
+application that it receives from the Compute layer.
 
 ## Networking Protocols
 
-The Oasis Network uses 3 main protocols for communication:
+The Oasis Network uses three different protocols for communication:
 
 * [Tendermint](https://github.com/tendermint/tendermint)
 * [grpc](https://grpc.io/)
@@ -34,5 +87,22 @@ The Oasis Network uses 3 main protocols for communication:
 
 Confidentiality is achieved in the Oasis Network by relying on trusted execution
 environments (TEEs) to secure the execution of any given smart contract.
-Initially, the Oasis Network will utilize [Intel SGX](https://software.intel.com/en-us/sgx).
-As more TEE technologies mature, we expect to support more than TEEs than Intel SGX.
+Initially, the Oasis Network will utilize [Intel
+SGX](https://software.intel.com/en-us/sgx). As more TEE technologies mature, we
+expect to support more than TEEs than Intel SGX.
+
+## Entities and Key Management
+
+Every Node that participates on the network is owned by a specific Entity. This
+Entity is not only a logical abstraction but is also a critical aspect of the
+key management model for node operators. The model is as follows:
+
+* Entity
+  * An Entity is an organization or individual with stake on the network
+  * Each Entity's key pair is used for:
+    * Registering Node IDs (Node's Public Key)
+    * Token transfers
+* Node
+  * A Node is a block producing node on the Oasis Network
+  * Each Node's key pair is used for:
+    * Signing actions during block production

src/operators/current-testnet-parameters.md

@@ -0,0 +1,8 @@
+# Current Testnet Parameters
+
+This page is meant to be kept up to date with the information from the currently
+released testnet. Use the information here to deploy or upgrade your node on the
+testnet.
+
+* [Link to Genesis Document]()
+* Oasis Seed Node Address (feel free to use other seed nodes):

src/operators/hardware-requirements.md → src/operators/hardware-recommendations.md

@@ -1,54 +1,54 @@
-# Node Hardware Requirements
+# Node Hardware Recommendations
 
-_The hardware requirements listed on this page are recommended minimum
+_The hardware configurations listed on this page are recommended minimum
 configurations. It might be possible to configure a system with less resources,
 but you run the risk of being underprovisioned and thereby prone to loss of
 stake._
 
-## Minimum System Requirements
+## Suggested Minimum Configurations
 
 As noted in the [Architectural Overview](./architectural-overview.md), the Oasis
-Network is composed of multiple classes of Nodes that perform specific
-functions. The majority of Node classes have common system requirements. All
-node types should support the following minimum requirements:
+Network is composed of multiple classes of Nodes that participate in different
+committees. The majority of committees have common system configurations for the
+participant Nodes. We suggest the following minimum recommendations:
 
 * 2.0 GHz x86-64
   * Must have AES-NI support
-* 4 GB ECC RAM
+* 2 GB ECC RAM
 * 500GB High Speed Storage
 
-### Node Class Additional Requirements
+### Additional Attributes By Committee
 
-Beyond the common system requirements, the following section details
-additional requirements for operating the different Node classes.
+Beyond the common system configurations, the following section details
+additional requirements or recommendations for operating Nodes to participate in
+different committees.
 
-#### Confidential Compute Layer Nodes
+#### Confidential Compute Committee Nodes
 
 As part of supporting confidential smart contracts in the future, the Oasis
 Network will utilize SGX in order to ensure privacy preserving computation. At
 this time, supporting SGX hardware is optional for Node Operators. However, for
 Node Operators who want to be to prepared for the eventual release of the
-confidential runtime, the following requirements should be met:
+confidential runtime, the network will require at least the following hardware:
 
 * CPU supports SGXv1 Support
 * BIOS supports enabling SGX
 * EPC limits should be set to the maximum 128MB
+  * Setting this value to the maximum is recommended but is not required.
 
-#### Storage Nodes
+#### Storage Committee Nodes
 
-At this time, the growth rate of state stored on storage nodes is unknown. Node
-operators should expect the minimum recommendations for storage to change over
-time.
-
-Recommended Minimum Configuration:
+At this time, the growth rate of state stored on storage nodes is unknown. We
+suggest that Node Operators configure their systems with the following
+hardware in order to handle storage growth over time:
 
 * 2TB High Speed Storage
 
-#### Key Management Nodes
+#### Key Manager Committee Nodes
 
 At this time, Key Management Nodes will only be operated by Oasis. However
 system requirements for the Key Manager nodes are currently identical to the
-confidential compute worker nodes.
+Confidential Compute Committee nodes.
 
 ### HSMs