chore: minor improvement for docs

docs/adr/adr-002-mempool.md

@@ -4,7 +4,7 @@ For now, mempool implementation from lazyledger-core/Tendermint will be used.
 
 ## Pros
 
-* good integration with other re-used code (see ADR-001)
+* good integration with other reused code (see ADR-001)
 * well tested
 * glue code is not required
 * it will be updated in case of ABCI++ adoption
@@ -23,6 +23,6 @@ For now, mempool implementation from lazyledger-core/Tendermint will be used.
 * Implementation from scratch
   * time consuming
   * error prone
-* Re-using other mempool (Celo, Prysm, etc)
+* Reusing other mempool (Celo, Prysm, etc)
   * different API
   * potential licensing issues

docs/adr/adr-003-peer-discovery.md

@@ -35,6 +35,6 @@ Libp2p provides multiple ways to discover peers (DHT, mDNS, PubSub peer exchange
 2. Custom peer-exchange protocol.
    - pros: full flexibility of implementation
    - cons: need to create from scratch and test
-3. Re-use of existing peer discovery mechanism like `discv5`
+3. Reuse of existing peer discovery mechanism like `discv5`
    - pros: ready & battle-tested software
    - cons: use different network stack, requires lot of integration

docs/learn/sequencing/overview.md

@@ -9,23 +9,23 @@ Sequencing is the essential first step for handling your transactions. Think of
 ```go
 // Sequencer is a generic interface for a sequencer
 type Sequencer interface {
- // SubmitBatchTxs submits a batch of transactions  to sequencer
+ // SubmitBatchTxs submits a batch of transactions to the sequencer
  // Id is the unique identifier for the target chain
  // Batch is the batch of transactions to submit
- // returns an error if any from the sequencer
+ // returns any error from the sequencer
  SubmitBatchTxs(ctx context.Context, req SubmitBatchTxsRequest) (*SubmitBatchTxsResponse, error)
 
- // GetNextBatch returns the next batch of transactions from sequencer to
+ // GetNextBatch returns the next batch of transactions from the sequencer to the chain
  // Id is the unique identifier for the target chain
- // LastBatchHash is the cryptographic hash of the last batch received by the
+ // LastBatchData contains the previous batch data received by the chain
  // MaxBytes is the maximum number of bytes to return in the batch
- // returns the next batch of transactions and an error if any from the sequencer
+ // returns the next batch of transactions and any error from the sequencer
  GetNextBatch(ctx context.Context, req GetNextBatchRequest) (*GetNextBatchResponse, error)
 
  // VerifyBatch verifies a batch of transactions received from the sequencer
  // Id is the unique identifier for the target chain
- // BatchHash is the cryptographic hash of the batch to verify
- // returns a boolean indicating if the batch is valid and an error if any from the sequencer
+ // BatchData contains the batch data to verify
+ // returns a boolean indicating whether the batch is valid and any error from the sequencer
  VerifyBatch(ctx context.Context, req VerifyBatchResponse) (*VerifyBatchResponse, error)
 }
 ```

types/header.go

@@ -108,7 +108,7 @@ func (h *Header) Height() uint64 {
 	return h.BaseHeader.Height
 }
 
-// LastHeader returns last header hash of the header.
+// LastHeader returns the last header hash.
 func (h *Header) LastHeader() Hash {
 	return h.LastHeaderHash[:]
 }
@@ -151,7 +151,7 @@ var (
 )
 
 // LegacyHeaderFields captures the deprecated header fields that existed prior
-// to the header minimisation change. When populated, these values are re-used
+// to the header minimisation change. When populated, these values are reused
 // while constructing the protobuf payload so that legacy nodes can continue to
 // verify signatures and hashes.
 //

types/tx.go

@@ -2,7 +2,7 @@ package types
 
 import "unsafe"
 
-// Tx represents transaction.
+// Tx represents a transaction.
 type Tx []byte
 
 // Txs represents a slice of transactions.