docs: fix typos (#772)

Author: MegaRedHand

Diff for: docs/architecture.md

@@ -9,17 +9,17 @@ subgraph "Consensus Node"
   engine[Engine API Client]
   BAPI[Beacon API]
   TICK[Slot processor]
-	blk_db[Block DB]
-	BS_db[Beacon State DB]
+  blk_db[Block DB]
+  BS_db[Beacon State DB]
   brod[Broadway]
-	FCTree[Fork choice store - Genserver]
+  FCTree[Fork choice store - Genserver]
   BAPI -->|Beacon state queries| BS_db
-	brod -->|Save blocks| blk_db
-	brod -->|Blocks and attestations| FCTree
-	TICK -->|New ticks| FCTree
+  brod -->|Save blocks| blk_db
+  brod -->|Blocks and attestations| FCTree
+  TICK -->|New ticks| FCTree
   BAPI --> engine
-	BAPI --> |head/slot requests| FCTree
-	brod --> |Save new states|BS_db
+  BAPI --> |head/slot requests| FCTree
+  brod --> |Save new states|BS_db
 end
 GOS[Gossip Protocols]
 exec[Execution Client]
@@ -31,20 +31,20 @@ VALIDATOR --> BAPI
 
 ## Networking
 
-The main entry for new events is the gossip protocol, which is the way in which our consensus node communicates with other consensus nodes. This includes:
+The main entry for new events is the gossip protocol, which is how our consensus node communicates with other consensus nodes. This includes:
 
 1. Discovery: our node has a series of known `bootnodes` hardcoded. We request a list of the nodes they know about and add them to our list. We save them locally and now can use those too to request new nodes.
 2. Message propagation. When a proposer sends a new block, or validators attest for a new block, they send those to other known nodes. Those, in turn, propagate the messages sent to other nodes. This process is repeated until, ideally, the whole network receives the messages.
 
-We use the `go-libp2p` library for the networking primitives, which is an implementation of the `libp2p`networking stack.
+We use the `go-libp2p` library for the networking primitives, which is an implementation of the `libp2p` networking stack.
 
-We use ports to communicate with a go application and broadway to process notifications.
+We use ports to communicate with a go application and Broadway to process notifications.
 
-**TO DO**: We need to document the ports architecture.
+**TO DO**: We need to document the port's architecture.
 
 ## Gossipsub
 
-One of the main communication protocols is gossipsub. This allows us to tell peers which topics we're interested in and receive events for them. The main external events we react to are blocks and attestations.
+One of the main communication protocols is GossipSub. This allows us to tell peers which topics we're interested in and receive events for them. The main external events we react to are blocks and attestations.
 
 ### Receiving an attestation
 
@@ -65,7 +65,7 @@ sequenceDiagram
 
 When receiving an attestation, it's processed by the [on_attestation](https://eth2book.info/capella/annotated-spec/#on_attestation) callback. We just validate it and send it to the fork choice store to update its weights and target checkpoints. The attestation is only processed if this attestation is the latest message by that validator. If there's a newer one, it should be discarded.
 
-The most relevant piece of the spec here is the [get_weight](https://eth2book.info/capella/annotated-spec/#get_weight) function, which is the core of the fork-choice algorithm. In the specs, this function is called on demand, when calling [get_head](https://eth2book.info/capella/annotated-spec/#get_head), works with the store's values and recalculates them each time. In our case, we cache the weights and the head root each time we add a block or attestation, so we don't need to do the same calculations again. 
+The most relevant piece of the spec here is the [get_weight](https://eth2book.info/capella/annotated-spec/#get_weight) function, which is the core of the fork-choice algorithm. In the specs, this function is called on demand, when calling [get_head](https://eth2book.info/capella/annotated-spec/#get_head), works with the store's values, and recalculates them each time. In our case, we cache the weights and the head root each time we add a block or attestation, so we don't need to do the same calculations again. 
 
 **To do**: we should probably save the latest messages in persistent storage as well so that if the node crashes we can recover the tree weights.
 
@@ -103,7 +103,7 @@ sequenceDiagram
 Receiving a block is more complex:
 
 - The block itself needs to be stored.
-- The state transition needs to be applied, a new beacon state calculated and stored separately.
+- The state transition needs to be applied, a new beacon state calculated, and stored separately.
 - A new node needs to be added to the block tree aside from updating weights.
 - on_attestation needs to be called for each attestation.
 

Diff for: docs/bindings_go.md

@@ -6,7 +6,7 @@ The bindings are used to interact with the *go-libp2p* and *go-ethereum/p2p* lib
 As we couldn't find a way to communicate the two languages directly, we used some **C** code to communicate the two sides.
 However, as Go is a garbage-collected language, this brings some issues.
 
-<!-- TODO: add explanation about general bindings usage -->
+<!-- TODO: add an explanation about general bindings usage -->
 <!-- TODO: explain the callback -> message translation -->
 
 ## References and handles
@@ -57,7 +57,7 @@ func SumAndConsumeArray(arrayHandle C.uintptr_t) uint {
 
 What we have until now allows us to create long-living references, but we still need to free them manually (otherwise we leak memory).
 To fix this, we can treat them as native objects with Erlang's [*Resource objects*](https://www.erlang.org/doc/man/erl_nif.html#functionality).
-By treating them as resources with an associated type and destructor, we can let Erlang's garbage-collector manage the reference's lifetime.
+By treating them as resources with an associated type and destructor, we can let Erlang's garbage collector manage the reference's lifetime.
 It works as follows:
 
 <!-- TODO: add code examples -->

Diff for: docs/bitvectors.md

@@ -2,13 +2,13 @@
 
 ## Representing integers
 
-Computers use transistors to store data. These electrical components only have two possible states: `clear` or `set`. Numerically, we represent the clear state as a `0` and and the set state as `1`. Using 1s and 0s, we can represent any integer number using the binary system, the same way we use the decimal system in our daily lives.
+Computers use transistors to store data. These electrical components only have two possible states: `clear` or `set`. Numerically, we represent the clear state as a `0` and the set state as `1`. Using 1s and 0s, we can represent any integer number using the binary system, the same way we use the decimal system in our daily lives.
 
-As an example, let's take the number 259. For its decimal representation, we use the digits 2, 5 and 9, because each digit, or coefficient, represents a power of 10:
+As an example, let's take the number 259. For its decimal representation, we use the digits 2, 5, and 9, because each digit, or coefficient, represents a power of 10:
 
 $$ 259 = 200 + 50 + 9 = 2*10^2 + 5*10^1 + 9*10^0 $$
 
-If we wanted to do the same the binary binary, we would use powers of two, and each individual symbol (or bit) can only be 0 or 1.
+If we wanted to do the same in the binary, we would use powers of two, and each symbol (or bit) can only be 0 or 1.
 
 $$ 259 = 256 + 2 + 1 = 1*2^{8} + 1*2^{1} + 1*2^0 $$
 
@@ -44,7 +44,7 @@ Representing it as a byte array, we get `bytes = [3, 1]`. The lowest index, `byt
 
 ### "Little-endian bit order"
 
-Why would we need a third representation? Let's first pose the problem. Imagine we have a fixed amount of validators, equal to 9, and we want to represent whether they attested in a block or not. If the validators 0, 1 and 8 attested, we may represent this with a boolean array, as follows:
+Why would we need a third representation? Let's first pose the problem. Imagine we have a fixed amount of validators, equal to 9, and we want to represent whether they attested in a block or not. If the validators 0, 1, and 8 attested, we may represent this with a boolean array, as follows:
 
 ```
 [true, true, false, false, false, false, false, false, true]
@@ -76,13 +76,13 @@ If we want to convert from each order to each other:
 
 - Little-endian byte order to big-endian: reverse the bytes.
 - Little-endian bit order to big-endian: reverse the bits of the whole number.
-- Little-endian bit order to little-endian byte order: reverse the bits of each individual byte. This is equivalent to reversing all bits (converting to big-endian) and then reversing the bytes (big-endian to little-endian byte order) but in a single step.
+- Little-endian bit order to little-endian byte order: reverse the bits of each byte. This is equivalent to reversing all bits (converting to big-endian) and then reversing the bytes (big-endian to little-endian byte order) but in a single step.
 
 ## Bit vectors
 
 ### Serialization (SSZ)
 
-`bitvectors` are exactly that: a set of booleans with fixed size. SSZ represents bit vectors as follows:
+`bitvectors` are exactly that: a set of booleans with a fixed size. SSZ represents bit vectors as follows:
 
 - Conceptually, a set is represented in little-endian bit ordering, padded with 0s at the end to get full bytes.
 - When serializing, we convert from little-endian bit ordering to little-endian byte ordering.
@@ -111,22 +111,22 @@ Moving it to little-endian byte order (we go byte by byte and reverse the bits):
 00000011 00000001
 ```
 
-This is how nodes send `bitvectors` over the network. We know that this array is of size 9 beforehand, so we know what bits are padding and should be ignored. For variable-sized bit arrays we'll use `bitlists`, which we'll talk about later.
+This is how nodes send `bitvectors` over the network. We know that this array is of size 9 beforehand, so we know what bits are padding and should be ignored. For variable-sized bit arrays, we'll use `bitlists`, which we'll talk about later.
 
 ### Internal representation
 
-There's a trick here: SSZ doesn't specify how to store a `bitvector` in memory after deserializing. We could, theoretically, read the serialized data, transform it from little-endian byte order to little-endian bit order, and use bit addressing (which elixir supports) to get individual values. This would imply, however, going through each byte and reversing the bits, which is a costly operation. If we stuck with little-endian byte order without transforming it, addressing individual bits would be more complicated, and shifting (moving every bit to the left or right) would be tricky.
+There's a trick here: SSZ doesn't specify how to store a `bitvector` in memory after deserializing. We could, theoretically, read the serialized data, transform it from little-endian byte order to little-endian bit order, and use bit addressing (which Elixir supports) to get individual values. This would imply, however, going through each byte and reversing the bits, which is a costly operation. If we stuck with little-endian byte order without transforming it, addressing individual bits would be more complicated, and shifting (moving every bit to the left or right) would be tricky.
 
 For this reason, we represent bitvectors in our node as big-endian binaries. That means that we reverse the bytes (a relatively cheap operation) and, for bit addressing, we just use the complementary index. An example:
 
-If we are still representing the number 259 (validators with index 0, 1 and 8 attested) we'll have the two following representations (note, elixir has a `bitstring` type that lets you address bit by bit and store an amount of bits that's not a multiple of 8):
+If we are still representing the number 259 (validators with index 0, 1, and 8 attested) we'll have the two following representations (note, elixir has a `bitstring` type that lets you address bit by bit and store several bits that's not a multiple of 8):
 
 ```
 110000001 -> little-endian bit order
 100000011 -> big-endian
 ```
 
-If we watch closely, we confirm something we said before: these are bit-mirrored representations. That means that if I want to know if the validator i voted, in the little-endian bit order, we address `bitvector[i]`, and in the big-endian order, we just use `bitvector[N-i]`, where `N=9` as it's the size of the vector.
+If we watch closely, we confirm something we said before: these are bit-mirrored representations. That means that if I want to know if the validator I voted, in the little-endian bit order, we address `bitvector[i]`, and in the big-endian order, we just use `bitvector[N-i]`, where `N=9` as it's the size of the vector.
 
 This is the code that performs this conversion:
 
@@ -139,9 +139,9 @@ def new(bitstring, size) when is_bitstring(bitstring) do
 end
 ```
 
-It reads the input as a little-endian number, and then constructs a big-endian binary representation of it.
+It reads the input as a little-endian number and then constructs a big-endian binary representation of it.
 
-Instead of using Elixir's bitstrings, a possible optimization (we'd need to benchmark it) would be to represent the array as the number 259 directly, and use bitwise operations to address bits or shift.
+Instead of using Elixir's bitstrings, a possible optimization (we'd need to benchmark it) would be to represent the array as the number 259 directly and use bitwise operations to address bits or shift.
 
 ## Bitlists
 
@@ -177,7 +177,7 @@ When deserializing, we'll look closely at the last byte, realize that there are
 
 ### Edge case: already a multiple of 8
 
-It might be the case that we already have a multiple of 8 as the number of booleans we're representing. For instance, let's suppose that we have 8 validators and only the first and the second one attested. In little-endian bit order, that is:
+It might be the case that we already have a multiple of 8 as the number of booleans we're representing. For instance, let's suppose that we have 8 validators and only the first and the second ones attested. In little-endian bit order, that is:
 
 ```
 11000000