docs: fix typos in specs (#228)

specs/README.md

@@ -30,7 +30,7 @@ that maintains 1:1 compatibility with Ethereum.
 Our aim is to design a protocol specification that is:
 
 - **Fast:** When users send transactions, they get reliable confirmations with low-latency.
-  For example when swapping on Uniswap you should see that your transaction succeed in less than 2
+  For example when swapping on Uniswap you should see that your transaction succeeds in less than 2
   seconds.
 - **Scalable:** It should be possible to handle an enormous number of transactions
   per second which will enable the system to charge low fees.

specs/batcher.md

@@ -17,7 +17,7 @@ The batch submitter, also referred to as the batcher, is the entity submitting t
 The format of the data transactions is defined in the [derivation spec]:
 the data is constructed from L2 blocks in the reverse order as it is derived from data into L2 [blocks][g-block].
 
-The timing, operation and transaction signing is implementation-specific: any data can be submitted at any time,
+The timing, operation and transaction signing are implementation-specific: any data can be submitted at any time,
 but only the data that matches the [derivation spec] rules will be valid from the validator perspective.
 
 The most minimal batcher implementation can be defined as a loop of the following operations:

specs/challenge.md

@@ -54,7 +54,7 @@ In the ZK fault-proof challenge process, the following undeniable bug might aris
 In the former case, the Security Council validates the legitimacy of the deleted output and, if the aforementioned
 error is identified, dismisses the challenge and initiates a rollback of the deleted output.
 In the latter scenario, all challengers will fail in proving the fault. In such cases, the Security Council verifies
-the output and, if deemed invalid, delete the output forcibly. All interventions by the Security Council are executed
+the output and, if deemed invalid, deletes the output forcibly. All interventions by the Security Council are executed
 through multi-sig transactions.
 
 ## State Diagram
@@ -74,7 +74,7 @@ through multi-sig transactions.
 5. When the asserter timed out or bisection is completed, the state of challenge will be `READY_TO_PROVE` automatically.
    At this state, the challenger is now able to pick the first invalid output and submit ZK fault proof.
    Likewise, the challenge is canceled if the output is already been deleted.
-6. If the submitted proof is turned out to be invalid, the state stays at `READY_TO_PROVE` until `PROVING_TIMEOUT` is
+6. If the submitted proof is turned out to be invalid, the state stays at `READY_TO_PROVE` until `PROVING_TIMEOUT` has
    occurred.
 7. Otherwise, `READY_TO_PROVE` state goes to `PROVEN`, and the L2 output is deleted.
 8. The deleted output would be validated by the **[Security Council][g-security-council]** to mitigate ZK soundness
@@ -109,7 +109,7 @@ abusing. As a result, after one interaction between parties, [ZK fault proof][g-
 verified on [L1][g-l1]. In reality, 1800 blocks are segmented using `SEGMENTS_LENGTHS`.
 
 Here we give a simple example with a small number to show you how it works. Let's say there are 11 blocks and the 3rd
-block is the block a challenger want to argue against and this number is decomposed into 5 and 2. Also, let's assume
+block is the block a challenger wants to argue against and this number is decomposed into 5 and 2. Also, let's assume
 that both of them agree the state transitions to the 2nd block.
 
 | Turn       | Action          | Segment Start | Segment Length | Segments        | Condition          |

specs/contract-upgrades.md

@@ -50,7 +50,7 @@ to be executed with a 7-day timelock. After the timelock delay, the upgrade can
      * @notice Function to queue a proposal to the timelock.
      *         Added protocol for using custom time-lock zero delay for urgent situations.
      *
-     * @param _targets         The destination address that send the message to.
+     * @param _targets         The destination address that sends the message to.
      * @param _values          Amount of ether sent with the message.
      * @param _calldatas       The data portion of the message.
      * @param _descriptionHash A hashed form of the description string.

specs/deposits.md

@@ -307,7 +307,7 @@ file will be located in the `deployedBytecode` field of the build artifacts file
 
 [User-deposited transactions][g-user-deposited] are [deposited transactions][deposited-tx-type]
 generated by the [L2 Chain Derivation][g-derivation] process. The content of each user-deposited
-transaction are determined by the corresponding `TransactionDeposited` event emitted by the
+transaction is determined by the corresponding `TransactionDeposited` event emitted by the
 [deposit contract][deposit-contract] on L1.
 
 1. `from` is unchanged from the emitted value (though it may

specs/derivation.md

@@ -274,7 +274,7 @@ Note the `101-0` L1 attributes transaction on the bottom right of the diagram. I
 frame `B2` indicates that it is the last frame within the channel and (2) no empty blocks must be inserted.
 
 The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4
-blocks, because the last frame of channel `A` appears in block 102, but belong to epoch 99.
+blocks, because the last frame of channel `A` appears in block 102, but belongs to epoch 99.
 
 As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
 

specs/glossary.md

@@ -241,7 +241,7 @@ Different transaction types can contain different payloads, and be handled diffe
 
 [fork-choice-rule]: glossary.md#fork-choice-rule
 
-The fork choice rule is the rule used to determined which [block] is to be considered as the head of a blockchain.
+The fork choice rule is the rule used to determine which [block] is to be considered as the head of a blockchain.
 On [L1], this is determined by the proof of stake rules.
 
 L2 also has a fork choice rule, although the rules vary depending on whether we want the [safe L2 head][safe-l2-head],
@@ -280,7 +280,7 @@ whose priority fee is high so that sequencer can earn maximum priority fee as a
 
 A sequencer is either a [rollup node][rollup-node] ran in sequencer mode, or the operator of this rollup node.
 
-The sequencer is a priviledged actor, which receives L2 transactions from L2 users, creates L2 blocks using them, which
+The sequencer is a privileged actor, which receives L2 transactions from L2 users, creates L2 blocks using them, which
 it then submits to [data availability provider][avail-provider] (via a [batcher]).
 
 > **TODO** In the initial release, the sequencer role is merged to the sequencer. In the future,
@@ -410,7 +410,7 @@ the remaining validators' transactions will fail and will not be recognized as o
 
 However, some of them will have already spent their gas.
 
-To handle this situation, we provide a option flag to indicate whether or not to participate in the public round.
+To handle this situation, we provide an option flag to indicate whether or not to participate in the public round.
 
 Since we're taking a conservative approach, the default value is set to false.
 
@@ -604,7 +604,7 @@ supported when they get deployed on Ethereum.
 
 [sequencer-batch]: glossary.md#sequencer-batch
 
-A sequencer batch is list of [L2] transactions (that were submitted to a sequencer) tagged with an [epoch
+A sequencer batch is a list of [L2] transactions (that were submitted to a sequencer) tagged with an [epoch
 number](#sequencing-epoch) and an L2 [block] timestamp (which can trivially be converted to a block number, given our
 block time is constant).
 
@@ -637,7 +637,7 @@ On the side of the [rollup node][rollup-node] (which is the consumer of channels
 [channel-frame]: glossary.md#channel-frame
 
 A channel frame is a chunk of data belonging to a [channel]. [Batcher transactions][batcher-transaction] carry one or
-multiple frames. The reason to split a channel into frames is that a channel might too large to include in a single
+multiple frames. The reason to split a channel into frames is that a channel might be too large to include in a single
 batcher transaction.
 
 ## Batcher
@@ -749,7 +749,7 @@ The L2 genesis [block] is the first block of the [L2] chain in its current versi
 
 The state of the L2 genesis block contains [Predeployed contracts][predeploy].
 
-The timestamp of the L2 genesis block must be a multiple of the [block time][block-time] (i.e. a even number, since the
+The timestamp of the L2 genesis block must be a multiple of the [block time][block-time] (i.e. an even number, since the
 block time is 2 seconds).
 
 When updating the rollup protocol to a new version, we may perform a _squash fork_, a process that entails the creation