docs(weaver, cactus): fix typos

[skip ci]

Co-authored-by: Peter Somogyvari <[email protected]>

Signed-off-by: GoodDaisy <[email protected]>
Signed-off-by: Peter Somogyvari <[email protected]>

docs/docs/cactus/packages/cactus-api-client.md

@@ -27,7 +27,7 @@ The above means that the `ApiClient` class is not the one containing the impleme
 
 For example you can use the `@hyperledger/cactus-api-client` node package to perform Cactus node discovery based on ledger IDs (that can be obtained from the `ConsortiumDatabase` as defined by the [generated models](https://github.com/hyperledger/cactus/blob/main/packages/cactus-core-api/src/main/typescript/generated/openapi/typescript-axios/api.ts) of the `@hyperledger/cactus-core-api` package.
 
-> While you can generate API Clients for the Cactus API specifications in any supported langauge of the [OpenAPI Generator](https://github.com/OpenAPITools/openapi-generator) the features provided by this package will have to be developed separately (if not already done by the Cactus maintainers). Currently the only implementation of the abstract API Client and its features (node discovery) is in Typescript (e.g. the `@hyperledger/cactus-api-client` package).
+> While you can generate API Clients for the Cactus API specifications in any supported language of the [OpenAPI Generator](https://github.com/OpenAPITools/openapi-generator) the features provided by this package will have to be developed separately (if not already done by the Cactus maintainers). Currently the only implementation of the abstract API Client and its features (node discovery) is in Typescript (e.g. the `@hyperledger/cactus-api-client` package).
 
 Usage
 --------------------------------------------

docs/docs/cactus/packages/cactus-cmd-api-server.md

@@ -213,7 +213,7 @@ Many different configurations are possible here as well. One way to have two mem
 
 This is an example to showcase how you can pull up a full consortium even from within a single operating system process (API server) with multiple members and their respective nodes. It is not something that’s recommended for a production grade environment, ever, but it is great for demos and integration tests where you have to simulate a fully functioning consortium with as little hardware footprint as possible to save on time and cost.
 
-The individual nodes/API servers are isolated by listening on seperate TCP ports of the machine they are hosted on:
+The individual nodes/API servers are isolated by listening on separate TCP ports of the machine they are hosted on:
 
 ![deployment-low-resource-example.png](https://github.com/hyperledger/cactus/raw/4a337be719a9d2e2ccb877edccd7849f4be477ec/whitepaper/deployment-low-resource-example.png)
 
@@ -375,7 +375,7 @@ This class creates a prometheus exporter, which scrapes the total Cactus node co
 
 ### Usage Prometheus
 
-The prometheus exporter object is initialized in the `ApiServer` class constructor itself, so instantiating the object of the `ApiServer` class, gives access to the exporter object. You can also initialize the prometheus exporter object seperately and then pass it to the `IApiServerConstructorOptions` interface for `ApiServer` constructor.
+The prometheus exporter object is initialized in the `ApiServer` class constructor itself, so instantiating the object of the `ApiServer` class, gives access to the exporter object. You can also initialize the prometheus exporter object separately and then pass it to the `IApiServerConstructorOptions` interface for `ApiServer` constructor.
 
 `getPrometheusMetricsV1` function returns the prometheus exporter metrics, currently displaying the total plugins imported, which currently refreshes to match the plugin count, everytime `setTotalPluginImports` method is called.
 

docs/docs/cactus/packages/cactus-plugin-consortium-manual.md

@@ -8,7 +8,7 @@ This class creates a prometheus exporter, which scrapes the total Cactus node co
 
 ### Usage Prometheus
 
-The prometheus exporter object is initialized in the `PluginConsortiumManual` class constructor itself, so instantiating the object of the `PluginConsortiumManual` class, gives access to the exporter object. You can also initialize the prometheus exporter object seperately and then pass it to the `IPluginConsortiumManualOptions` interface for `PluginConsortiumManual` constructor.
+The prometheus exporter object is initialized in the `PluginConsortiumManual` class constructor itself, so instantiating the object of the `PluginConsortiumManual` class, gives access to the exporter object. You can also initialize the prometheus exporter object separately and then pass it to the `IPluginConsortiumManualOptions` interface for `PluginConsortiumManual` constructor.
 
 `getPrometheusMetricsV1` function returns the prometheus exporter metrics, currently displaying the total cactus node count, which currently refreshes to match the node count in the consortium, everytime `updateMetricNodeCount` method of the `PluginConsortiumManual` class is called.
 

docs/docs/cactus/packages/cactus-plugin-keychain-vault.md

@@ -8,7 +8,7 @@ This class creates a prometheus exporter, which scrapes the transactions (total
 
 ### Usage
 
-The prometheus exporter object is initialized in the `PluginKeychainVault` class constructor itself, so instantiating the object of the `PluginKeychainVault` class, gives access to the exporter object. You can also initialize the prometheus exporter object seperately and then pass it to the `IPluginKeychainVaultOptions` interface for `PluginKeychainVault` constructor.
+The prometheus exporter object is initialized in the `PluginKeychainVault` class constructor itself, so instantiating the object of the `PluginKeychainVault` class, gives access to the exporter object. You can also initialize the prometheus exporter object separately and then pass it to the `IPluginKeychainVaultOptions` interface for `PluginKeychainVault` constructor.
 
 `getPrometheusMetricsV1` function returns the prometheus exporter metrics, currently displaying the total key count, which currently increments everytime the `set()` and `delete()` method of the `PluginKeychainVault` class is called.
 

docs/docs/cactus/packages/cactus-plugin-ledger-connector-besu.md

@@ -21,7 +21,7 @@ Summary
 
 *   [Prometheus Exporter](#prometheus-exporter)
 
-*   [Runing the tests](#running-the-tests)
+*   [Running the tests](#running-the-tests)
 
 *   [Built With](#built-with)
 
@@ -55,7 +55,7 @@ The sequence diagrams for various endpoints are mentioned below
 
 #### run-transaction-endpoint
 
-![run-transaction-endpoint sequence diagram](../_images/run-transaction-endpoint.png) The above diagram shows the sequence diagram of run-transaction-endpoint. User A (One of the many Users) interacts with the API Client which in turn, calls the API server. API server then executes transact() method which is explained in detailed in the subsequent diagrams. ![run-transaction-endpoint transact() method](../_images/run-transaction-endpoint-transact.png) The above diagram shows the sequence diagram of transact() method of the PluginLedgerConnectorBesu class. The caller to this function, which in reference to the above sequence diagram is API server, sends RunTransactionRequest object as an argument to the transact() method. Based on the type of Web3SigningCredentialType, corresponsing responses are sent back to the caller.  
+![run-transaction-endpoint sequence diagram](../_images/run-transaction-endpoint.png) The above diagram shows the sequence diagram of run-transaction-endpoint. User A (One of the many Users) interacts with the API Client which in turn, calls the API server. API server then executes transact() method which is explained in detailed in the subsequent diagrams. ![run-transaction-endpoint transact() method](../_images/run-transaction-endpoint-transact.png) The above diagram shows the sequence diagram of transact() method of the PluginLedgerConnectorBesu class. The caller to this function, which in reference to the above sequence diagram is API server, sends RunTransactionRequest object as an argument to the transact() method. Based on the type of Web3SigningCredentialType, corresponding responses are sent back to the caller.  
 ![run-transaction-endpoint transactCactusKeychainRef() method](../_images/run-transaction-endpoint-transact-cactuskeychainref.png) The above diagram shows transactCactusKeychainReference() method being called by the transact() method of the PluginLedgerConnector class when the Web3SigningCredentialType is CACTUSKEYCHAINREF. This method inturn calls transactPrivateKey() which calls the signTransaction() method of web3 library. ![runtransaction-endpoint transactPrivateKey() method](../_images/run-transaction-endpoint-transact-privatekey.png) The above diagram shows transactPrivateKey() method being called by the transact() method of the PluginLedgerConnector class when the Web3SigningCredentialType is PRIVATEKEYHEX. This method then calls the signTransaction() method of the web3 library. ![run-transaction-endpoint transactSigned() method](../_images/run-transaction-endpoint-transact-signed.png) The above diagram shows transactSigned() method being called by the transact() method of the PluginLedgerConnector class when the Web3SigningCredentialType is NONE. This method calls the sendSignedTransaction() of the web3 library and then calls pollForTxReceipt() method. ![run-transaction-endpoint pollForTxReceipt() method](../_images/run-transaction-endpoint-transact-pollfortxreceipt.png) The above diagram shows pollForTxReceipt() method which is called by the transactSigned() method as described in the previous sequence diagram. This method waits for the block confirmation in a loop and then sends the corresponding response back to the caller.
 
 ### Usage
@@ -252,7 +252,7 @@ This class creates a prometheus exporter, which scrapes the transactions (total
 
 ### Prometheus Exporter Usage
 
-The prometheus exporter object is initialized in the `PluginLedgerConnectorBesu` class constructor itself, so instantiating the object of the `PluginLedgerConnectorBesu` class, gives access to the exporter object. You can also initialize the prometheus exporter object seperately and then pass it to the `IPluginLedgerConnectorBesuOptions` interface for `PluginLedgerConnectoBesu` constructor.
+The prometheus exporter object is initialized in the `PluginLedgerConnectorBesu` class constructor itself, so instantiating the object of the `PluginLedgerConnectorBesu` class, gives access to the exporter object. You can also initialize the prometheus exporter object separately and then pass it to the `IPluginLedgerConnectorBesuOptions` interface for `PluginLedgerConnectoBesu` constructor.
 
 `getPrometheusMetricsV1` function returns the prometheus exporter metrics, currently displaying the total transaction count, which currently increments everytime the `transact()` method of the `PluginLedgerConnectorBesu` class is called.
 

docs/docs/weaver/architecture-and-design/drivers.md

@@ -9,9 +9,9 @@ title: Drivers
  SPDX-License-Identifier: CC-BY-4.0
  -->
 
-The driver is responsible for all communication between the relay and its network. In the previous sections we have thought about the driver as a component of the relay. We have done this because conceptually it makes sense to think about it like that. However, in our reference implementation we have made it a seperate process which communicates with the relay via gRPC, as shown below. There are two main reasons for this:
+The driver is responsible for all communication between the relay and its network. In the previous sections we have thought about the driver as a component of the relay. We have done this because conceptually it makes sense to think about it like that. However, in our reference implementation we have made it a separate process which communicates with the relay via gRPC, as shown below. There are two main reasons for this:
 
-1. There must exist a different driver for each network type (e.g. Fabric, Corda etc.) and therefore having the driver as a seperate process makes it easy to "plug" different drivers into the relay.
+1. There must exist a different driver for each network type (e.g. Fabric, Corda etc.) and therefore having the driver as a separate process makes it easy to "plug" different drivers into the relay.
 2. A possible use case of the relay is that a single relay instance may have multiple drivers (e.g. if multiple entities in the network want to run their own driver). In this case, this plugin style approach of drivers makes it possible to do without having to modify code for each configuration.
 
 ![](../../../images-weaver-docs/architecture-assets/driver_architecture.png)

docs/docs/weaver/architecture-and-design/weaver-dapps.md

@@ -21,11 +21,11 @@ When Fabric is the responding network, the IOP module is in charge of verifying
 
 ![](../../../images-weaver-docs/architecture-assets/fabric_dapp_flow2.png)
 
-Verification Policy, Access Control and Membership are modular components within the interop chaincode for seperation of concerns of the code.
+Verification Policy, Access Control and Membership are modular components within the interop chaincode for separation of concerns of the code.
 
 ## Corda
 
-As can be seen from the diagrams below, the architecture for Corda is very similar to that of Fabric. The main difference is that the interop module and the application specific flows are in seperate CorDapps, instead of seperate chaincodes like in Fabric.
+As can be seen from the diagrams below, the architecture for Corda is very similar to that of Fabric. The main difference is that the interop module and the application specific flows are in separate CorDapps, instead of separate chaincodes like in Fabric.
 
 ![](../../../images-weaver-docs/architecture-assets/corda_dapp_flow1.png)