Fix: typos (ethereum#362)

* Fix: typo

Fix: typo

* Fix: typos

Fix: typos

* Fix: typo

Fix: typo

README.md

@@ -73,7 +73,7 @@ information.
 
 [View the spec][graphql-schema]
 
-[EIP-1767][eip-1767] proposed a GraphQL schema for interacting with Ethereum clients. Since then Besu and Geth have implemented the interface. This repo contains a live specification to integrate changes to the protocol as well as other improvements into the GraphQL shema.
+[EIP-1767][eip-1767] proposed a GraphQL schema for interacting with Ethereum clients. Since then Besu and Geth have implemented the interface. This repo contains a live specification to integrate changes to the protocol as well as other improvements into the GraphQL schema.
 
 ### Generation
 

docs/making-changes.md

@@ -43,7 +43,7 @@ there can be a huge variance in actual design decisions.
 
 As an example, a proposal for a method such as `eth_totalSupply` seems
 reasonable. This is a quantity that users are often interested in and it would
-nice to have it available. However, tracking the total supply is tricky. There
+be nice to have it available. However, tracking the total supply is tricky. There
 are several avenues where ether can enter and leave supply. This method would
 need to either i) compute the value on demand or ii) store value for each block
 height.
@@ -64,13 +64,13 @@ method be created.
 
 ## Standardization
 
-There is not a formal process for standardization of API changes. However, the
-outline below should given proposal authors and champions a rough process to
+There is no formal process for standardization of API changes. However, the
+outline below should give proposal authors and champions a rough process to
 follow.
 
 ### Idea
 
-An often overlooked aspect on the standardization journey is the idea phase.
+An often overlooked aspect of the standardization journey is the idea phase.
 This is an important period of time, because some focused effort at this point
 in time can save time and make the rest of the process much smoother.
 
@@ -109,7 +109,7 @@ clients. This should be expected and not discourage authors.
 After client teams acknowledge and accept the change, it is usually on them to
 implement the method in their client. Due to the lack of versioning of the API,
 it is preferable that clients release the method roughly at the same time so
-that there is not much time where some clients support a certain methods and
+that there is not much time when some clients support certain methods and
 others don't.
 
 

src/engine/paris.md

@@ -272,7 +272,7 @@ The payload build process is specified as follows:
 
 4. Consensus Layer client software **SHOULD** poll this endpoint every 60 seconds.
 
-5. Execution Layer client software **SHOULD** surface an error to the user if it does not recieve a request on this endpoint at least once every 120 seconds.
+5. Execution Layer client software **SHOULD** surface an error to the user if it does not receive a request on this endpoint at least once every 120 seconds.
 
 6. Considering the absence of the `TERMINAL_BLOCK_NUMBER` setting, Consensus Layer client software **MAY** use `0` value for the `terminalBlockNumber` field in the input parameters of this call.