Merge pull request #71 from chronicleprotocol/updateDiagram

Update FeedRegistry to ValidatorRegistry

Author: biancabuzea200

docs/Intro/dive/dive.md

@@ -1,10 +1,12 @@
  # Architecture
 
-  The Chronicle's Oracle protocol comprises a distributed architecture spanning both on-chain and off-chain components. The diagram below highlights both types of components, with off-chain components depicted with a green on the left-hand side, and on-chain components (purple) on the right-hand side. 
+  The Chronicle's Oracle protocol comprises a distributed architecture spanning both on-chain and off-chain components. The diagram below highlights both types of components, with off-chain components depicted with a green on the left-hand side, and on-chain components (brown) on the right-hand side. 
 
   Origins, such as primary data sources, can exist on both on-chain and off-chain layers.
 
-    ![Example banner](../../../static/img/diagram.png)
+    ![Diagram Image](../../../static/img/Intro/diagram.png)
+  
+
 
     To read in further detail about our approach to on-chain and off-chain usage please view the sub menu options under Architecture.
 

docs/Intro/dive/offchain.md

@@ -2,11 +2,11 @@
 
     - **Validator** (aka Feed) Creates usable information out of raw data that is read from various Origins. Validators query Origins no matter whether they are on-chain or off-chain for the price data. The Validator transform the original data into Chronicle data by using Data Models. After the Chronicle data is calculated it is signed and sent to the peer-to-peer network.
 
-    - **Challenger** is an off chain component that listens to Oracle’s updates and makes sure that no invalid optimistic update is made. Thus we can be sure that our Optimistic Oracles are functioning properly. Both challengers and relays are permissionless jobs with challengers even getting paid for their effort. Participation from the community is both encouraged and supported.
+    - **Challenger** is an offchain component that listens to Oracle’s updates and makes sure that no invalid optimistic update is made. Thus we can be sure that our Optimistic Oracles are functioning properly. Both challengers and relays are permissionless jobs with challengers even getting paid for their effort. Participation from the community is both encouraged and supported.
 
-    - **Origins** are the data sources about the assets prices that can exist on chain (DEX) such as UniSwap, dYdX, Balancer, etc. or be off chain from CEXs ( e.g. Kraken, Binance, Coinbase).
+    - **Origins** are the data sources about the asset prices that can exist on-chain (DEX) such as UniSwap, dYdX, Balancer, etc. or be offchain from CEXs ( e.g. Kraken, Binance, Coinbase).
 
-    - **Relays** collect data from Validators/Feeds and compose EVM transactions out of it. Subsequently, these EVM transactions with the Feeds data is sent to a blockchain. 
+    - **Relays** collect data from Validators/Feeds and compose EVM transactions out of it. Subsequently, these EVM transactions with the Validators data is sent to a blockchain. 
 
     - **Archiver** aggregates the messages created by Validators and stores it in a database. It collect all signed messages, not the intermediate messages like used for MuSig creating.
 

docs/Intro/dive/onchain.md

@@ -8,12 +8,12 @@ sidebar_position: 1
     - **List of Validators**: This refers to the entities or individuals who are authorized to participate in the MultiSig validation process for a particular data model. MultiSig validation typically requires multiple parties to sign off on a transaction or data update before it is considered valid. The list of validators outlines who these authorized parties are.
     - **Quorum**: This represents the minimum number of validations or "feeds" required for a MultiSig validation to be considered valid for a specific data model. For example, if the quorum for a particular data model is set to 11, it means that exactly 11 out of the total number of validators listed must sign off on the transaction or data update for it to be accepted.
 
-     - By storing this information for each data model, **WatRegistry** ensures that the MultiSig validation process is conducted according to the specified requirements for each particular data model. Chronicle Protocol facilitates the dynamic updating of configurations for feeds using the Chronicles Go-based Oracle client. **ConfigRegistry** assigns a unique URL to each individual feed. This unique URL mechanism allows for the management of distinct configurations for every feed. In essence, the **ConfigRegistry** serves as a central repository where configuration information for each feed is stored and can be updated as needed. By maintaining this registry, Chronicle Protocol ensures that each feed can have its own specific configuration settings tailored to its requirements, enhancing flexibility and customization within the protocol
+     - By storing this information for each data model, **WatRegistry** ensures that the MultiSig validation process is conducted according to the specified requirements for each particular data model. Chronicle Protocol facilitates the dynamic updating of configurations for validators using the Chronicles Go-based Oracle client. **ConfigRegistry** assigns a unique URL to each individual validator. This unique URL mechanism allows for the management of distinct configurations for every validator. In essence, the **ConfigRegistry** serves as a central repository where configuration information for each validator is stored and can be updated as needed. By maintaining this registry, Chronicle Protocol ensures that each validator can have its own specific configuration settings tailored to its requirements, enhancing flexibility and customization within the protocol
 
-    - **FeedRegistry** plays a crucial role within the **Chronicle Protocol** by maintaining a comprehensive list of all Feeds that are recognized as valid participants in the network/protocol. Feeds, in this context, are trusted entities within the network that collaborate through a *peer-to-peer* (p2p) network to supply new oracle data.
+    - **ValidatorRegistry** plays a crucial role within the **Chronicle Protocol** by maintaining a comprehensive list of all Validators that are recognized as valid participants in the network/protocol. Validators, in this context, are trusted entities within the network that collaborate through a *peer-to-peer* (p2p) network to supply new oracle data.
 
-    - An on-chain enforced consensus mechanism ensures that data provided by these Feeds is validated by a specific number, known as the `bar` of Feeds. As a singleton contract deployed on the Ethereum blockchain, the **FeedRegistry** serves as a centralized source of truth regarding the identities of valid Feeds within the Chronicle Protocol. Feeds regularly query this registry to determine their status within the network. Additionally, the registry provides functionalities such as filtering p2p connections based on the identities of Feeds and translating feed addresses to/from their corresponding 1-byte identifier.
-    By leveraging the **FeedRegistry**, Chronicle Protocol ensures that only authenticated and authorized Feeds participate in the network activities, thereby enhancing the security and integrity of the oracle data provided by the protocol.
+    - An on-chain enforced consensus mechanism ensures that data provided by these Validators is validated by a specific number, known as the `bar` of Validators. As a singleton contract deployed on the Ethereum blockchain, the **ValidatorRegistry** serves as a centralized source of truth regarding the identities of valid Validators within the Chronicle Protocol. Validators regularly query this registry to determine their status within the network. Additionally, the registry provides functionalities such as filtering p2p connections based on the identities of Validators and translating validator addresses to/from their corresponding 1-byte identifier.
+    By leveraging the **ValidatorRegistry**, Chronicle Protocol ensures that only authenticated and authorized Validators participate in the network activities, thereby enhancing the security and integrity of the oracle data provided by the protocol.