Docs improvements

docs/docs/blog/2021-01-21-cross-chain-asset.md

@@ -11,7 +11,7 @@
 ## Introduction
 Recent years have witnessed a growing demand for enabling interoperability across independent blockchains. Cross-chain asset exchange is a significant step towards blockchain interoperability. For public blockchains, the most popular application for asset exchange is cryptocurrency exchange. For permissioned blockchains, cross-chain asset exchange can be useful in [Delivery Versus Payment (DvP)](https://www.mas.gov.sg/-/media/MAS/ProjectUbin/Project-Ubin-DvP-on-Distributed-Ledger-Technologies.pdf) and [cross-border payment](https://www.mas.gov.sg/-/media/Jasper-Ubin-Design-Paper.pdf) scenarios. There exist various protocols designed for asset exchange on public blockchains. However, a widely adopted standard for designing such protocols for permissioned blockchains still does not exist. Moreover, most existing protocols are designed for public blockchains and their suitability to be applied to permissioned blockchains is unclear.
 
-In this article, we aim to lay out a set of requirements for designing cross-chain asset exchange protocols between permissioned blockchains. First we present a canonical motivating use case and then list the various patterns that such cases will follow in real-life scenarios. We then present a short survey of existing cross-chain exchange protocols for public blockchains, following which we summarise the building blocks, core mechanisms and security properties commonly involved in the protocol designs. We then analyse the requirements imposed by permissioned blockchains in comparison to public blockchains, and discuss the additional properties with respect to these restrictions.
+In this article, we aim to lay out a set of requirements for designing cross-chain asset exchange protocols between permissioned blockchains. First we present a canonical motivating use case and then list the various patterns that such cases will follow in real-life scenarios. We then present a short survey of existing cross-chain exchange protocols for public blockchains, following which we summarise the building blocks, core mechanisms and security properties commonly involved in the protocol designs. We then analyze the requirements imposed by permissioned blockchains in comparison to public blockchains, and discuss the additional properties with respect to these restrictions.
 
 ## Motivation and Use-case
 In traditional financial markets parties trade assets such as securities and derivatives for cash or other assets. To reduce risk, various clearing and settlement processes and intermediaries are often involved. One form of settlement is a DvP where the transfer of securities is performed only in the event of a corresponding payment. This arrangement reduces principal risk by ensuring that both parties receive their end of the exchange. However, settlement in financial markets are slow and time consuming. It also involves counterparty risks and requires intermediaries.

docs/docs/blog/2021-01-21-emergence-enterprise-interoperability.md

@@ -27,9 +27,9 @@ Sometime in the first half of the previous decade, it was recognized that networ
 - Transactions can be audited by trusted authorities when required for dispute resolutions, and
 - Higher performance and assurance can be gained using consensus protocols other than _proof-of-work_.
 
-Since companies and consortia were wary of this new and unproven technology, the trend in industry these past few years has been to build _minimum viable ecosystems_, i.e., networks of limited operational scope and participation. The goal being to evaluate the potential of blockchain, these networks were created to manage selected few assets and records. Needless to say, interoperation with other networks was not high on the priority list when such networks were designed and launched.
+Since companies and consortia were wary of this new and unproven technology, the trend in industry these past few years has been to build _minimum viable ecosystems_, i.e., networks of limited operational scope and participation. The goal is to evaluate the potential of blockchain, these networks were created to manage selected few assets and records. Needless to say, interoperation with other networks was not high on the priority list when such networks were designed and launched.
 
-Many of these networks have been successfully validated and put into production. But a consequence of the decision to build limited-scope networks is that the processes they run (through smart contracts) and the assets and records they maintain on their ledgers are stuck in siloes, inaccessible to external entitites and networks. Yet, as we are discovering, processes and assets in such networks are inextricably linked in the real enterprise world. With all of the investment (in time and money) made in existing networks, reeingeneering or merging them will generally be hardsells. Also, some networks may wish to restrict operational control and ledger visibility to its current set of administrators and clientele. The only viable solution is to allow networks to interoperate, thereby breaking up the siloes, while retaining operational control.
+Many of these networks have been successfully validated and put into production. But a consequence of the decision to build limited-scope networks is that the processes they run (through smart contracts) and the assets and records they maintain on their ledgers are stuck in siloes, inaccessible to external entities and networks. Yet, as we are discovering, processes and assets in such networks are inextricably linked in the real enterprise world. With all of the investment (in time and money) made in existing networks, reengineering or merging them will generally be hardsells. Also, some networks may wish to restrict operational control and ledger visibility to its current set of administrators and clientele. The only viable solution is to allow networks to interoperate, thereby breaking up the siloes, while retaining operational control.
 
 ## Diverse Platforms
 Our present blockchain landscape (or ecosystem) is characterized not just by a plethora of networks, a mix of open and private, but also by the existence of several distinct blockchain technologies, each with a different storage technology, a different model for contracts and client applications, a different consensus protocol, and a different way of managing identity. Examples include Fabric, Iroha, Sawtooth, and Besu, all in the Hyperledger family, and Ethereum, Multichain, Cardano, and Komodo, outside it. There are also smart contract distributed ledger platforms that serve a similar set of business applications that are not blockchains at all, like R3's Corda.

docs/docs/cactus/build.md

@@ -109,7 +109,7 @@ Getting Started
 
     *   Docker Compose
 
-    *   OpenJDK (Corda support Java 8 JDK but do not currently support Java 9 or higher)
+    *   OpenJDK (Corda support Java 8 JDK but does not currently support Java 9 or higher)
 
         *   `sudo apt install openjdk-8-jdk-headless`
 

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

@@ -422,7 +422,7 @@ FAQ
 
 ### What is the difference between a Cactus Node and a Cactus API Server?
 
-The node is what has an identity within your PKI and can be made up of 1-N API server instances that all share the same configuration/identity of the node. See deployment scenarios above for a much more detailed explanation.
+The node is what has an identity within your PKI and can be made up of 1-N API server instances that all share the same configuration/identity of the node. See the deployment scenarios above for a much more detailed explanation.
 
 ### Is the API server horizontally scalable?
 

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

@@ -30,7 +30,7 @@ Once edited, you can start the prometheus service by referencing the above edite
 
 #### response.type.ts
 
-This file contains the various responses of the metrics.
+This file contains the various responses to the metrics.
 
 #### data-fetcher.ts
 

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

@@ -30,7 +30,7 @@ Once edited, you can start the prometheus service by referencing the above edite
 
 #### response.type.ts
 
-This file contains the various responses of the metrics.
+This file contains the various responses to the metrics.
 
 #### data-fetcher.ts