Merge pull request #10 from CrisBRM/more-english-fixes

More english fixes

README.md

@@ -17,7 +17,7 @@ The directory structure of the document is defined in the README.rst file in the
 3. Each language is allowed to have its own temporary version. It is recommended to add the suffix version number to the version name, for example, en1.0, zh-CN1.1;
 
 ## How to build this project?
-1. clone the project from github, here is for master bratch:
+1. clone the project from github, next command refers to the master branch:
 
 ```bash
 git clone https://github.com/nebulasio/nebdocs.git
@@ -36,7 +36,7 @@ make html
 ```
 
 ## How to add a new document?
-### If just add a file
+### If you need to add a file
 1. Add the file to the appropriate directory;
 2. Locate the README.rst file in the directory where the file is located (the project root directory is index.rst file), open the file, and add the newly added file name to the file list after the 'toctree' keyword. E.g:
 
@@ -87,7 +87,7 @@ The contents of the folder/README.rst file should be:
 
 ## How to add a new language version?
 
-1. Create a new branch, for the Chinese version example:
+1. Create a new branch, for the chinese version, for instance:
 ```bash
 Git checkout -b zh-CN
 ```
@@ -111,4 +111,4 @@ Html_context = {
 ```bash
 Git push --set-upstream zh-CN
 ```
-5. Notify the manager to add a new language version to the readthedocs' online documentation.
+5. Notify the manager to add a new language version to the readthedocs' online documentation.

docs/infrastructure/crypto/README.md

@@ -1,36 +1,36 @@
 # Crypto Design Doc
 
-Similar to Bitcoin and Ethereum, Nebulas also adopts elliptic curve algorithm as its basic encryption algorithm for Nebulas transactions. Users' private key will be encrypted with user's passphrases and stored in keystore.
+Similar to Bitcoin and Ethereum, Nebulas also adopted an elliptic curve algorithm as its basic encryption algorithm for Nebulas transactions. Users' private keys will be encrypted with their passphrases and stored in a keystore.
 
 ## Hash
 
-Support generic hash functions, like sha256, sha3256 and ripemd160 etc.
+Supports generic hash functions, like sha256, sha3256 and ripemd160 etc.
 
 ## Keystore
 
-Nebulas Keystore are designed to manage user's keys.
+The Nebulas Keystore is designed to manage users' keys.
 
 ### Key
 
 The Key interface is designed to support various keys, including symmetric keys and asymmetric keys.
 
 ### Provider
 
-Keystore provide different methods to save keys, such as `memory_provider` and `persistence_provider`. Before saved, key has been encrypted in keystore.
+The Keystore provides different methods to save keys, such as `memory_provider` and `persistence_provider`. Before storage, the key has been encrypted in the keystore.
 
-* `memory provider`: This type of provider keep keys in memory. After the key has been encrypted with the passphrase when user setkey or load, it is cached in memory provider.
-* `persistence provider`: This type of provider serialize the encrypted key to the file. The file is compatible with the ethereum's keystore file，users can back up the address with its privatekey in it.
+* `memory provider`: This type of provider keeps the keys in memory. After the key has been encrypted with the passphrase when the user setkey or loads, it is cached in memory provider.
+* `persistence provider`: This type of provider serializes the encrypted key to the file. The file is compatible with Ethereum's keystore file. Users can back up the address with its privatekey in it.
 
 ### Signature
 
-The Signature interface is used to provide applications the functionality of a digital signature algorithm. A Signature object can be used to generate and verify digital signatures.
+The Signature interface is used to provide applications with the functionality of a digital signature algorithm. A Signature object can be used to generate and verify digital signatures.
 
-There are two phases to use a Signature object for either signing data :
+There are two phases, in order to use a Signature object for signing data :
 
 * Initialization: with a private key, which initializes the signature for signing \(see initSign\(\) in the source code of go-nebulas\).
-* Signing on all input bytes.
+* Signing of all input bytes.
 
-A Signature object can recover the public key with a signatrue and the plain text was singed on\(see function RecoverSignerFromSignature in go-nebulas\). So just comparing the from address and the address derived from the public key can verfiy a transaction
+A Signature object can recover the public key with a signature and the plain text that was signed \(see function RecoverSignerFromSignature in go-nebulas\). So just comparing the from address and the address derived from the public key can verify a transaction
 
-> Similar as [Android Keystore](https://developer.android.com/training/articles/keystore.html), TPM, TEE and hardware low level security protection will be supported as a provider later.
+> Similar to the [Android Keystore](https://developer.android.com/training/articles/keystore.html), TPM, TEE and hardware low level security protection will be supported as a provider later.
 

docs/infrastructure/crypto/README.rst

@@ -1,20 +1,21 @@
 Crypto Design Doc
 =================
 
-Similar to Bitcoin and Ethereum, Nebulas also adopts elliptic curve
+Similar to Bitcoin and Ethereum, Nebulas also adopted an elliptic curve
 algorithm as its basic encryption algorithm for Nebulas transactions.
-Users’ private key will be encrypted with user’s passphrases and stored
-in keystore.
+Users' private keys will be encrypted with their passphrases and stored
+in a keystore.
+
 
 Hash
 ----
 
-Support generic hash functions, like sha256, sha3256 and ripemd160 etc.
+Supports generic hash functions, like sha256, sha3256 and ripemd160 etc.
 
 Keystore
 --------
 
-Nebulas Keystore are designed to manage user’s keys.
+The Nebulas Keystore is designed to manage user’s keys.
 
 Key
 ~~~
@@ -25,37 +26,38 @@ symmetric keys and asymmetric keys.
 Provider
 ~~~~~~~~
 
-Keystore provide different methods to save keys, such as
-``memory_provider`` and ``persistence_provider``. Before saved, key has
-been encrypted in keystore.
+The Keystore provides different methods to save keys, such as 
+`memory_provider` and `persistence_provider`. Before storage, 
+the key has been encrypted in the keystore.
 
--  ``memory provider``: This type of provider keep keys in memory. After
+-  ``memory provider``: This type of provider keeps the keys in memory. After
    the key has been encrypted with the passphrase when user setkey or
    load, it is cached in memory provider.
--  ``persistence provider``: This type of provider serialize the
-   encrypted key to the file. The file is compatible with the ethereum’s
-   keystore file，users can back up the address with its privatekey in
+-  ``persistence provider``: This type of provider serializes the
+   encrypted key to the file. The file is compatible with Ethereum’s
+   keystore file. Users can back up the address with its privatekey in
    it.
 
 Signature
 ~~~~~~~~~
 
-The Signature interface is used to provide applications the
-functionality of a digital signature algorithm. A Signature object can
-be used to generate and verify digital signatures.
+The Signature interface is used to provide applications with the 
+functionality of a digital signature algorithm. A Signature object
+can be used to generate and verify digital signatures.
+
 
-There are two phases to use a Signature object for either signing data :
+There are two phases, in order to use a Signature object for signing data :
 
 -  Initialization: with a private key, which initializes the signature
    for signing (see initSign() in the source code of go-nebulas).
--  Signing on all input bytes.
+-  Signing of all input bytes.
 
-A Signature object can recover the public key with a signatrue and the
-plain text was singed on(see function RecoverSignerFromSignature in
+A Signature object can recover the public key with a signature and the
+plain text that was signed (see function RecoverSignerFromSignature in
 go-nebulas). So just comparing the from address and the address derived
-from the public key can verfiy a transaction
+from the public key can verify a transaction
 
-   Similar as `Android
+   Similar to the `Android
    Keystore <https://developer.android.com/training/articles/keystore.html>`__,
    TPM, TEE and hardware low level security protection will be supported
    as a provider later.
@@ -64,4 +66,4 @@ from the public key can verfiy a transaction
 .. toctree::
     :titlesonly:
 
-    nvm.md
+    nvm.md

docs/infrastructure/crypto/nvm.md

@@ -1,17 +1,17 @@
 # NVM - Nebulas Virtual Machine
 
-NVM is one of the most important components in Nebulas. As the name described, it provides a managed virtual machine execution environments for Smart Contract and Protocol Code.
+NVM is one of the most important components in Nebulas. As the name implies, it provides managed virtual machine execution environments for Smart Contract and Protocol Code.
 
-[go-nebulas](https://github.com/nebulasio/go-nebulas) now support two kinds of Virtual Machine:
+[go-nebulas](https://github.com/nebulasio/go-nebulas) now support two kinds of Virtual Machines:
 
 * V8: [Chrome V8](https://developers.google.com/v8/)
 * LLVM: [Low-Level Virtual Machine](https://llvm.org)
 
 ## Nebulas V8 Engine
 
-In go-nebulas, we design and implement [Nebulas V8 Engine](https://github.com/nebulasio/wiki/blob/master/nebulas_v8.md) based on Chrome V8.
+In go-nebulas, we designed and implemented the [Nebulas V8 Engine](https://github.com/nebulasio/wiki/blob/master/nebulas_v8.md) based on Chrome V8.
 
-Nebulas V8 Engine provides a high performance sandbox for [Smart Contract](https://github.com/nebulasio/wiki/blob/master/smart_contract.md) execution. It guarantees user deployed code is running in a managed environment, and prevents massive resource consumption on hosts. Owing to use of Chrome V8, [JavaScript](https://en.wikipedia.org/wiki/JavaScript) and [TypeScript](https://en.wikipedia.org/wiki/TypeScript) are first-class languages for Nebulas [Smart Contract](https://github.com/nebulasio/wiki/blob/master/smart_contract.md). Anyone familiar with JavaScript or TypeScript can write their own Smart Contract and run it in Nebulas V8.
+The Nebulas V8 Engine provides a high performance sandbox for [Smart Contract](https://github.com/nebulasio/wiki/blob/master/smart_contract.md) execution. It guarantees user deployed code is running in a managed environment, and prevents massive resource consumption on hosts. Owing to the use of Chrome V8, [JavaScript](https://en.wikipedia.org/wiki/JavaScript) and [TypeScript](https://en.wikipedia.org/wiki/TypeScript) are first-class languages for Nebulas [Smart Contracts](https://github.com/nebulasio/wiki/blob/master/smart_contract.md). Anyone familiar with JavaScript or TypeScript can write their own Smart Contract and run it in Nebulas V8.
 
 The following content is an example of Smart Contract written in JavaScript:
 
@@ -63,9 +63,9 @@ BankVaultContract.prototype = {
 module.exports = BankVaultContract;
 ```
 
-For more information about the smart contract in Nebulas, please go to [Smart Contract](https://github.com/nebulasio/wiki/blob/master/smart_contract.md).
+For more information about smart contracts in Nebulas, please go to [Smart Contract](https://github.com/nebulasio/wiki/blob/master/smart_contract.md).
 
-For more information about the design of Nebulas V8 Engine, please go to [Nebulas V8 Engine](https://github.com/nebulasio/wiki/blob/master/nebulas_v8.md).
+For more information about the design of the Nebulas V8 Engine, please go to [Nebulas V8 Engine](https://github.com/nebulasio/wiki/blob/master/nebulas_v8.md).
 
 ## LLVM
 

docs/infrastructure/network_protocol.md

@@ -1,14 +1,14 @@
 # Network Protocol
 
-For the network protocol, there are lots of existing solution. However, the Nebulas Team finally decides to define our own wire protocol, ensures the following principles to design the protocol:
+For the network protocol, there were a lot of existing solutions. However, the Nebulas Team decided to define their own wire protocol, and ensure the use of the following principles to design it:
 
 * the protocol should be simple and straight.
-* the message can be verified before receiving all package, fail early.
-* the protocol should be debugging friendly, developer can easily understand the raw message.
+* the messages can be verified before receiving all the packets, and fail early.
+* the protocol should be debugging friendly, so that the developer can easily understand the raw message.
 
 ## Protocol
 
-In Nebulas, we define our own wire protocol, as the following:
+In Nebulas, we define our own wire protocol as follows:
 
 ```text
  0               1               2               3              (bytes)
@@ -41,10 +41,10 @@ In Nebulas, we define our own wire protocol, as the following:
 ```
 
 * Magic Number: 32 bits \(4 chars\)
-  * The protocol magic number, A constant numerical or text value used to identify protocol.
+  * The protocol's magic number, a numerical constant or text value used to identify the protocol.
   * Default: 0x4e, 0x45, 0x42, 0x31
 * Chain ID: 32 bits
-  * The Chain ID is used to distinguish the test network and the main network.
+  * The Chain ID is used to distinguish the test network from the main network.
 * Reserved: 24 bits
   * reserved field.
   * The first bit indicates whether the network message is compressed.
@@ -62,13 +62,13 @@ In Nebulas, we define our own wire protocol, as the following:
 * Data: variable length, max 512M.
   * The message data.
 
-We always use Big-Endian in message protocol.
+We always use Big-Endian on the message protocol.
 
 ## Handshaking Messages
 
 * Hello
 
-the handshaking message when peer connect to others.
+the handshaking message when a peer connects to another.
 
 ```text
 version: 0x1
@@ -94,7 +94,7 @@ data: struct {
 
 * Bye
 
-the message to close connection.
+the message to close the connection.
 
 ```text
 version: 0x1

docs/infrastructure/permission_control_in_smart_contract.md

@@ -2,15 +2,15 @@
 
 ## What Is Permission Control Of Smart Contract
 
-The permission control of a smart contract refers to whether the contract caller has permission to invoke the function in the contract. There are two types of permission control: owner permission control and other permission control.
+The permission control of a smart contract refers to whether the contract caller has permission to invoke a given function in the contract. There are two types of permission control: owner permission control, and other permission control.
 
 Owner permissions control: Only the creator of the contract can call this method, other callers can not call the method.
 
 Other permission control: The contract method can be invoked if the contract developer defines a conditional caller according to the contract logic. Otherwise, it cannot be invoked.
 
 ## Owner Permission Control
 
-If you want to specify a owner to a small contract and wish if some functions could be called only by the owner and no one else. You can use following lines of code in your smart contract.
+If you want to specify an owner for a small contract and wish that some functions could only be called by the owner and no one else, you can use following lines of code in your smart contract.
 
 ```javascript
 "use strict";
@@ -35,11 +35,11 @@ module.exports = BankVaultContract;
 
 Explanation:
 
-The function init is only called once when the contract is deployed, there you specify the owner of the contract.The onlyOwnerFunctiuon ensures that the function is called by the owner of contact.
+The function init is only called once when the contract is deployed, so it is there that you can specify the owner of the contract.The onlyOwnerFunctiuon ensures that the function is called by the owner of contract.
 
 ## Other Permission Control
 
-In your smart contract, if you need to specify other permission control to a smart contract. For example, in your smart contract, you need to verify the transaction value in your smart contract. you can write your smart contract in the following way.
+In your smart contract, if you needed to specify other permission control, for example, if you needed to verify its transaction value, you could write it the following way.
 
 ```javascript
 'use strict';
@@ -113,10 +113,10 @@ module.exports = SampleContract;
 
 Explanation:
 
-Mixin.UNPAYABLE,Mixin.PAYABLE,Mixin.POSITIVE ,Mixin.UNPOSITIVE are permission control function。The permission control function as follows:
+Mixin.UNPAYABLE,Mixin.PAYABLE,Mixin.POSITIVE ,Mixin.UNPOSITIVE are permission control function。The permission control function is as follows:
 
-* Mixin.UNPAYABLE:  check the transaction sent value, if value is less than 0 return true, otherwise returns false
-* Mixin.UNPAYABLE : check the transaction sent value, if value is greater than 0 return true, otherwise returns false
+* Mixin.UNPAYABLE:  check the transaction sent value, if value is less than 0 return true, otherwise return false
+* Mixin.UNPAYABLE : check the transaction sent value, if value is greater than 0 return true, otherwise return false
 * Mixin.UNPOSITIVE ：output log UNPOSITIVE
 * Mixin.POSITIVE ：output log POSITIVE
 
@@ -128,31 +128,31 @@ Implement permission control in Mixin.decorator：
 
 Permission control tests in smart contracts are as follows:
 
-* The permission control function of the contract1 is Mixin.POSITIVE. If the permission check passes, the output is printed, otherwise the error is thrown by the permission check function.
+* The permission control function of the contract1 is Mixin.POSITIVE. If the permission check passes, the output is printed, otherwise an error is thrown by the permission check function.
 
   ```javascript
         contract1: Mixin.decorator(Mixin.POSITIVE, function (arg) {
             console.log("contract1 function:", arg);
         })
   ```
 
-* The permission control function of the contract2 is Mixin.UNPOSITIVE. If the permission check passes, the output is printed, otherwise the error is thrown by the permission check function.
+* The permission control function of the contract2 is Mixin.UNPOSITIVE. If the permission check passes, the output is printed, otherwise an error is thrown by the permission check function.
 
   ```javascript
         contract2: Mixin.decorator(Mixin.UNPOSITIVE, function (arg) {
                   console.log("contract2 function:", arg);
         })
   ```
 
-* The permission control function of the contract3 is Mixin.PAYABLE, Mixin.POSITIVE. If the permission check passes, the output is printed, otherwise the error is thrown by the permission check function.
+* The permission control function of the contract3 is Mixin.PAYABLE, Mixin.POSITIVE. If the permission check passes, the output is printed, otherwise an error is thrown by the permission check function.
 
   ```javascript
        contract3: Mixin.decorator(Mixin.PAYABLE, Mixin.POSITIVE, function (arg) {
                   console.log("contract3 function:", arg);
         })
   ```
 
-* The permission control function of the contract4 is Mixin.PAYABLE, Mixin.UNPOSITIVE. If the permission check passes, the output is printed, otherwise the error is thrown by the permission check function.
+* The permission control function of the contract4 is Mixin.PAYABLE, Mixin.UNPOSITIVE. If the permission check passes, the output is printed, otherwise an error is thrown by the permission check function.
 
   ```javascript
         contract4: Mixin.decorator(Mixin.PAYABLE, Mixin.UNPOSITIVE, function (arg) {
@@ -162,7 +162,7 @@ Permission control tests in smart contracts are as follows:
 
 Tips:
 
-With reference to the above example, the developer needs only three steps to implement other permission controls:
+With reference to the above example, the developer needs only three steps in order to implement other permission controls:
 
 * Implement permission control functions.
 * Implement the decorator function, and the permission check is completed by the conditional statement if \(typeof func !== "function" \|\| !func\(\)\).