fixed the misspelled

readthedocs/docs/contest/case-custom-policy.rst

@@ -16,7 +16,7 @@ In mitum, there are several factors for policy, these factors can control how mi
 
 
 ``threshold``
-    By default, ``threshold`` is ``67`` percent. This means how many node should agree on voting stage. ``67`` percent needs 2/3 of all nodes. If it is ``100``, nodes agree unanimously.
+    By default, ``threshold`` is ``67`` percent. This means how many nodes should agree on voting stage. ``67`` percent needs 2/3 of all nodes. If it is ``100``, nodes agree unanimously.
 
 ``interval_broadcast_init_ballot_in_join``
     This factor can control how often node will send *INIT* ballot in *join* state. If ``3s``, node will send *INIT* ballot every 3 seconds.

readthedocs/docs/contest/case-draw.rst

@@ -5,4 +5,4 @@ DRAW: Voting Result Ends in Tie
 
 .. todo::
 
-    This section will be describied later.
+    This section will be described later.

readthedocs/docs/contest/case-sync.rst

@@ -5,5 +5,5 @@ Sync
 
 .. todo::
 
-    This section will be describied later.
+    This section will be described later.
 

readthedocs/docs/contest/case-voting-failure-timeout.rst

@@ -2,13 +2,13 @@
 Voting Failure: Timeout
 ================================================================================
 
-INIT Stage
+Failure Of INIT Stage
 --------------------------------------------------------------------------------
 
 :Under situation:
 
-    * Suffrage group members votes for INIT stage.
-    * Some of nodes does not offer the INIT ballot,
+    * Suffrage group members vote for INIT stage.
+    * Some nodes does not offer the INIT ballot,
     * The number of these nodes is over *blocking number*.
     * Timed out in a given time, each node fails to get enough ballots for INIT stage.
 
@@ -31,11 +31,11 @@ INIT Stage
 
 :Expected actions:
 
-    * Each node stops the consensus process and changes it's state to *Joining*.
+    * Each node stops the consensus process and changes its state to *Joining*.
     * Each node will request *VoteProof* to the others.
 
 
-Proposing
+Failure Of Proposing
 --------------------------------------------------------------------------------
 
 :Under situation:
@@ -50,13 +50,13 @@ Proposing
     * Each node broadcasts next INIT ballots for next round.
 
 
-SIGN, ACCEPT Stages
+Failure Of SIGN, ACCEPT Stages
 --------------------------------------------------------------------------------
 
 :Under situation:
 
-    * Suffrage group members votes for SIGN stage.
-    * Some of nodes in **acting suffrage group** does not offer the SIGN ballot.
+    * Suffrage group members vote for SIGN stage.
+    * Some nodes in **acting suffrage group** does not offer the SIGN ballot.
     * Timed out in a given time, each node fails to get enough ballots for SIGN
       stage.
 

readthedocs/docs/contest/condition.rst

@@ -2,7 +2,7 @@
 Condition
 ============================================================
 
-``condition`` field can be defined in the top level of The config file. The sub fields can be defined with condition expressions.
+``condition`` field can be defined in the top-level of The config file. The sub fields can be defined with condition expressions.
 
 .. code-block:: yaml
    :linenos:
@@ -44,7 +44,7 @@ Basically the section of condition field has these structure:
                 - experssion #2
                 - experssion #3
 
-``all`` section is pre-defined section, the conditions in ``all`` section, will be applied to all the nodes. For example, the conditions under ``node_state`` should be matched to all nodes. ``new_block`` also too.
+``all`` section is predefined section, the conditions in ``all`` section, will be applied to all the nodes. For example, the conditions under ``node_state`` should be matched to all nodes. ``new_block`` also too.
 
 .. note::
 

readthedocs/docs/contest/index.rst

@@ -2,8 +2,8 @@
 Contest: ISAAC+ Consensus Simulator
 ============================================================
 
-There are huge amount of documentations for various kind of consensus protocol
-and also there are lots of implementations for helping to understand it's
+There are huge amounts of documentations for various kind of consensus protocol
+and also there are lots of implementations for helping to understand its
 mechanism. Contest is the implementation for simulating the detailed mechanism
 of ISAAC+.
 

readthedocs/docs/contribution.rst

@@ -2,7 +2,7 @@
 Contribution
 ============================================================
 
-Mitum started as opensource project and it will be. Any kind of contribution will be welcome. At this time, mitum needs your help at this parts:
+Mitum started as open source project and it will be. Any kind of contribution will be welcome. At this time, mitum needs your help at these parts:
 
 * Development
 * Documentation

readthedocs/docs/how-mitum-works.rst

@@ -16,19 +16,19 @@ As described in the section, ":doc:`introduction`", the mitum network consists o
 
 As mitum is blockchain, basically mitum network tries to store the incoming data by trusted way. This is simple process for new data.
 
-1. New message is received by one of nodes in the network
-2. New message contains the user data
-3. Message and it's data are validated by the nodes
-4. Each node tries to get the agreement for the new message and it's data
-5. If nodes get agreement to store new data, the new data will be established in the next block
+1. New message is received by one of nodes in the network.
+2. New message contains the user data.
+3. Message and it's data are validated by the nodes.
+4. Each node tries to get the agreement for the new message and it's data.
+5. If nodes get agreement to store new data, the new data will be established in the next block.
 
 The important things in the process are,
 
 * The agreement will be done by the consensus protocol, ISAAC+, and the agreement is made by voting with consensus nodes
-* All the incoming message is validated by consensus nodes
-* Only agreed data is established(stored) in the block
+* All the incoming message is validated by consensus nodes.
+* Only agreed data is established(stored) in the block.
 
-This is the normal process of PBFT-based blockchain. Mitum follows the classic scenario of PBFT.
+This is the normal process of PBFT based blockchain. Mitum follows the classic scenario of PBFT.
 
 Uncompressed Version
 ============================================================

readthedocs/docs/introduction.rst

@@ -2,31 +2,31 @@
 Introduction
 ============================================================
 
-Mitum is a general privacy blockchain with flexible and resilient way. Mitum can be used for various kind of purposes, public and private blockchain like  cryptocurrency network, data-centric blockchain for arbitrary data, or secure anonymity voting system, etc.
+Mitum is a general privacy blockchain with flexible and resilient way. Mitum can be used for various kind of purposes, public and private blockchain like cryptocurrency network, data-centric blockchain for arbitrary data, or secure anonymity voting system, etc.
 
-Basically mitum can provides these main features.
+Basically mitum can provide these main features.
 
 * **SECURITY**: All the in-coming and out-coming messages is signed, so there will be no chance some damaged or malicious messages to be infiltrated. 
 
-* **DESIGNING NETWORK**: mitum network is designed at bootstrap with various policies, network own data types and it's native features. These designed factors can be updated without downtime or termination of node and the entire network. 
+* **DESIGNING NETWORK**: mitum network is designed at bootstrap with various policies, network own data types and its native features. These designed factors can be updated without downtime or termination of node and the entire network. 
 
 * **APPLIANCE**: Data in mitum can be defined and designed. Any arbitrary type of data can be supported in mitum. Inside mitum there is a plugin system, so new type of data can be added thru plugin. If you want to launch cryptocurrency network, you can design currency model, define your own currency unit and even inflation rate, etc.
 
-* **CONSENSUS**:  mitum guarantees finality. Once the block and it's data are established, it will not be changed or revoked.
+* **CONSENSUS**: mitum guarantees finality. Once the block and it's data are established, it will not be changed or revoked.
 
-* **CONSENSUS**: mitum verifies and establishes data by the consensus protocol. We created the consensus protocol, called ISAAC+, which is newly devised and based on the manner of PBFT. ISAAC+ focuses on finality of block. It guarantees liveness, security and limited fault tolerance. ISAAC+ can be extended for the open and public environment, so new  nodes can join the network without the external allowance.
+* **CONSENSUS**: mitum verifies and establishes data by the consensus protocol. We created the consensus protocol, called ISAAC+, which is newly devised and based on the manner of PBFT. ISAAC+ focuses on finality of block. It guarantees liveness, security and limited fault tolerance. ISAAC+ can be extended for the open and public environment, so new nodes can join the network without the external allowance.
 
-* **CONSENSUS**: ISAAC+ works like well-hardened axe, it is hard to break and resilient from external impact. When some of nodes are not intact, it tries to continue agreement. When some blocks are lost in nodes, these data are restored without breaking consensus, the missed consensus messages also be delivered to the edge of network. 
+* **CONSENSUS**: ISAAC+ works like well-hardened axe, it is hard to break and resilient from external impact. When some nodes are not intact, it tries to continue agreement. When some blocks are lost in nodes, these data are restored without breaking consensus, the missed consensus messages also be delivered to the edge of network. 
 
-* **CONSENSUS**: Due to ISAAC+, mitum can process huge amount of messages, like currency transactions, consensus ballots, or any kind of messages for agreement. 
+* **CONSENSUS**: Due to ISAAC+, mitum can process huge amounts of messages, like currency transactions, consensus ballots, or any kind of messages for agreement. 
 
 * **DATA PRIVACY**: For privacy of user, mitum supports untraceable account. Basically thanks to the consensus process, accounts can be easily traced by anyone, who did fund it, who sent to it, whom it sent, and it's related data too. But unlike zcash, or hyperledge, mitum tries to support the privacy by transparent account. Transparent account can be created by the legitimate account, but hides which source account makes it. It breaks the link from the originated source account. 
 
 * **DATA**: All the data is stored by hierarchical tree structure(AVL tree). It makes to store and search data efficiently.
 
 * **DATA**: mitum does only rely on the data in the established data in block. The volatile data in node will not be used for consensus process and most of important data will be saved in block, so it can be updated by agreement by consensus protocol.
 
-* **NETWORK**: the basic networking protocol is UDP for consensus process . By the nature of UDP, there is no need to keep or check  the connection between consensus nodes.
+* **NETWORK**: the basic networking protocol is UDP for consensus process. By the nature of UDP, there is no need to keep or check the connection between consensus nodes.
 
 * **DATA**: mitum supports various kind of storage database: LevelDB, MongoDB, MySQL, PostgreSQL, etc. By the purpose and scale of mitum network, you can choose the best storage database.
 

readthedocs/docs/isaac+/how-isaac+-works.rst

@@ -2,7 +2,7 @@
 ISAAC+ Mechanism
 ============================================================
 
-As described at the previous section, the consensus voting is processed thru voting stages, *INIT*, *SIGN* and *ACCEPT*. The node, which can participate in consensus process, set it's state to *Consensus* state. If node is under other state, it means node is not ready for participating consensus process.
+As described at the previous section, the consensus voting is processed thru voting stages, *INIT*, *SIGN* and *ACCEPT*. The node, which can participate in consensus process, set its state to *Consensus* state. If node is under other state, it means node is not ready for participating consensus process.
 
 Voting and Round
 ------------------------------------------------------------
@@ -11,7 +11,7 @@ In ISAAC+, node votes to make agreement with the others. How node can vote? The
 
 Every node knows which nodes are in suffrage group and which nodes are in acting suffrage group at this stage and round. The member information does not need to be shared or synced, because it is managed and established at block like other data of block.
 
-Voting occurs by round. For example, latest block is ``H33``,
+Voting occurs by round. For example, the latest block is ``H33``,
 
 #. *INIT* : ``H34``, ``R0``
 #. *SIGN* : ``H34``, ``R0``

readthedocs/docs/isaac+/isaac+-compare-with-classic-pbft.rst → readthedocs/docs/isaac+/isaac+-compares-with-classic-pbft.rst

@@ -45,7 +45,7 @@ Each stage does have similar meaning.
 
 *SIGN*
     * Only members of acting suffrage group participate.
-    * Similar to the *Pre-Prepare*, the selected proposer(leader in PBFT) broadcasts it's proposal to the network
+    * Similar to the *Pre-Prepare*, the selected proposer(leader in PBFT) broadcasts its proposal to the network
     * Similar to the *Prepare*, each node will validate the proposal
 
 *ACCEPT*

readthedocs/docs/isaac+/isaac+-weakness-and-limitations.rst

@@ -7,11 +7,11 @@ Too obviously ISAAC+ is not perfect as consensus protocol. At this time, ISAAC+
 One Node Performance ≒  Entire Network Performance
 ------------------------------------------------------------
 
-The performance at this point is the ability how much contents can be handled at a time. With ISAAC+, the performance of entire network is almost same with the performance of one node. That is to say, one node can decide the maximum amount of contents for one block. At the worst case, the performance of entire network set to the one of poorest node.
+The performance at this point is the ability how much contents can be handled at a time. With ISAAC+, the performance of entire network is almost same with the performance of one node. That is to say, one node can decide the maximum amount of contents for one block. At the worst case, the performance of entire network set to the one of the poorest node.
 
-This problem is not native to ISAAC+, most of implementation of PBFT suffers same problem.
+This problem is not native to ISAAC+, most of the implementation of PBFT suffers same problem.
 
-To solve this problem, ISAAC+ has the suffrage group. Network designer designs it's network at the first time, the designer will set the several policies for new member for suffrage group like:
+To solve this problem, ISAAC+ has the suffrage group. Network designer designs its network at the first time, the designer will set the several policies for new member for suffrage group like:
 
 * Low network latency
 * Enough computing power
@@ -31,6 +31,6 @@ Network designer can decide how much time node will wait for the expected ballot
 Too many ballot messages between suffrage group
 ------------------------------------------------------------
 
-ISAAC+ works by voting and voting is done by ballot messages. All the members of suffrage group should broadcast it's own ballot to the others. The more node participate network, the number of messages will be increased exponentially. 
+ISAAC+ works by voting and voting is done by ballot messages. All the members of suffrage group should broadcast its own ballot to the others. The more node participate network, the number of messages will be increased exponentially. 
 
 Usually the size of ballot message is very tiny, but huge messages always will be a big burden in most systems. To reduce the problem, mitum basically rely on the UDP network layer and binary messaging serialization.

readthedocs/docs/isaac+/node-states.rst

@@ -43,12 +43,12 @@ States
 Booting
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* Node is just deployed and prepare it's resources to join the network.
+* Node is just deployed and prepare its resources to join the network.
 
 Syncing
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* The newly started node tries to sync it's block state to the latest of network.
+* The newly started node tries to sync its block state to the latest of network.
 * If node can not participate consensus, that means, it is not in suffrage group, it will stay the *Syncing* state for syncing the latest block state.
 
 Joining
@@ -66,5 +66,5 @@ Consensus
 Stopped
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* By any reason  when node is stopping or stopped.
+* By any reason when node is stopping or stopped.