Fix spelling errors

Signed-off-by: Nana Essilfie-Conduah <nana@swirldslabs.com>

Author: Nana-EC

HIP/hip-1081.md

@@ -47,7 +47,7 @@ to support DApps.
 Some notable challenges of the existing architecture include
 
 - Users must query the consensus node for latest state information
-- Consensus nodes must rely on other consensus nodes to be taught latest hashgraph information in order to catch up
+- Consensus nodes must rely on other consensus nodes to be taught latest Hashgraph information in order to catch up
 - Consensus nodes don’t offer proof of state APIs
 - Community members are unable to easily run independent nodes with complete state and transaction information that
 support the verification of the consensus outputs
@@ -59,13 +59,13 @@ on decentralization and promote client diversity.
 
 As such open, easy, performant and extensible communication is needed.
 The block node will utilize gRPC framework over the HTTP/2 protocol for communication. 
-gRPC was chosen due to the HTTP/2 suport, cross language and platform communitcation support (client diversity), high
-performance streaming, use of protobufs (continued committment to simple and clean API specification) via protobufs and
+gRPC was chosen due to the HTTP/2 support, cross language and platform communication support (client diversity), high
+performance streaming, use of protobufs (continued commitment to simple and clean API specification) via protobufs and
 flexibility with microservice pluggable options.
 
-As such consumers will utilzie gRPC clients to communicate.
+As such consumers will utilize gRPC clients to communicate.
 This matches the communication protocol with the CN but differs from other web3 nodes which often utilize JSON RPC APIs over HTTP.
-In the future it may be valuable to explore and add additonal protocol such as WS and HTTP (REST API, graphQL) based on community needs.
+In the future it may be valuable to explore and add additional protocol such as WS and HTTP (REST API, graphQL) based on community needs.
 
 
 
@@ -81,14 +81,14 @@ Highlight CN(s) -> BN -> MN + block stream clients
 
 ### Upgradeability
 
-It is a goal of a block node to be easy to run by users across differenat, languages, platform and cloud hosting
-resources. Today the netowrk requires that consensus nodes all run the same software to esnure integrity and optimal
+It is a goal of a block node to be easy to run by users across different, languages, platform and cloud hosting
+resources. Today the network requires that consensus nodes all run the same software to ensure integrity and optimal
 management of the network. Block nodes should not require this strict rule and instead should offer the ability to
 upgrade disconnected to the network consensus node version.
 
-Retrictions may exist when it comes to block stream protobuf versions, however, the block node will be forward
+Restrictions may exist when it comes to block stream protobuf versions, however, the block node will be forward
 compatible ensuring that new information added to the block stream can still be parsed, verified, stored and served up
-even if the block node does not yet have full undertsanding of the byte contents.
+even if the block node does not yet have full understanding of the byte contents.
 
 The block node will support semantic version values and will make it's current version available via API requests.
 
@@ -267,19 +267,19 @@ service StateService {
 
 <aside>
 🚨 **Open Task:** Flesh out 3 different state related query endpoints
-1. State snapshot - covering latest state and hsitorical state. All cases represent verified state at the end of a block.
-2. State changes e.g. what state changes occured in block x, this is a subset of the block query and avoid the transmission of extra block information beyond state
+1. State snapshot - covering latest state and historical state. All cases represent verified state at the end of a block.
+2. State changes e.g. what state changes occurred in block x, this is a subset of the block query and avoid the transmission of extra block information beyond state
   - Add new endpoint to proto
 3. Single entity state query e.g. return account 0.0.x 
   - Add new endpoint to proto
 </aside>
 
 #### Reconnect Service
 
-Today the network consensus node act as teachers to each other when a new node comes onlien and needs to ge the latest
-hashgraph information and state. To ensure future sclaability it's improtant to relive the consensus node of any
-unnecessary functionality that expens time and network resources that should be focused on transactions execution and
-hashgraph state management.
+Today the network consensus node act as teachers to each other when a new node comes online and needs to ge the latest
+Hashgraph information and state. To ensure future scalability it's important to relive the consensus node of any
+unnecessary functionality that expends time and network resources that should be focused on transactions execution and
+Hashgraph state management.
 
 As such the block node will replace the teaching role of a consensus node today and serve as a reliable teacher to any
 consensus node or block node coming online and looking for latest network details.
@@ -294,11 +294,11 @@ consensus node or block node coming online and looking for latest network detail
 #### Proof Service
 
 Consensus nodes provided proof of state APIs has long been desired, however, this would put additional work on the
-consensus node that could be better provied elsewhere. By maintaining live state and streaming block stream information
+consensus node that could be better provided elsewhere. By maintaining live state and streaming block stream information
 a block node can finally fill this gap and provide users with proofs including that of state.
 
 <aside>
-🚨 **Open Task:** Flesh out repsonse components
+🚨 **Open Task:** Flesh out response components
 Noting the 3 different proof types
 1. Block Proof
 2. Block Item Proof 
@@ -307,11 +307,11 @@ Noting the 3 different proof types
 
 ### Discovery
 
-To ensure a robust decentralized network it is improtant for block nodes to be easily discovered by clients.
+To ensure a robust decentralized network it is important for block nodes to be easily discovered by clients.
 
 <aside>
 🚨 **Open Task:** Explain how block nodes provide discovery details. 
-Cosniderations
+Considerations
 - Are they self reported?
 - Are they onchain?
 - What requirements if any are there for a block node and operator?
@@ -326,11 +326,11 @@ Cosniderations
 
 ### Monetization
 
-Block nodes will perform significant work by consuming the sblock stream, verifying it, storing it and providing
+Block nodes will perform significant work by consuming the block stream, verifying it, storing it and providing
 multiple API services to further users. To block node operators it is thus important to offer capabilities to cover
 the cost of work and encourage a vibrant economy.
 
-To achieve this the Block Node will adopt a charge card compareable model with crypto transfers of hbar required prior to the
+To achieve this the Block Node will adopt a charge card comparable model with crypto transfers of hbar required prior to the
 consumption of APIs. The block node will initially manage an hbar ledger on node to track the remaining hbar balance
 that an account ID holds with the block node.
 
@@ -339,7 +339,7 @@ To achieve this it is required that a block node have it's own account Id that u
 API costs will vary based on API but will include flat fees per request and variable fees based on size of data and
 complexity.
 
-Notably, monetization should be confirueable and allows for free or reduce cost pathwyas. For example a council node
+Notably, monetization should be configurable and allows for free or reduce cost pathways. For example a council node
 operator would likely run its block node and not expect calls from it to be charged.
 
 <aside>
@@ -379,7 +379,7 @@ affects the total latency observed, and the fees paid.
 To effectively educate and inform users about block node operation, comprehensive technical documentation, blogs, and
 webinars will be essential. Technical documentation will provide detailed and in-depth explanations of operation modes,
 usage, and best practices, ensuring that developers and mirror node operators can fully understand and transition to
-block stream consmption from a block node as well as block node hosting.
+block stream consumption from a block node as well as block node hosting.
 
 Blogs will offer more accessible and engaging content, highlighting use cases, real-world applications, and the benefits
 of a block node, catering to a broader audience of Hedera stakeholders. Webinars will serve as interactive platforms
@@ -414,7 +414,7 @@ a Block.
 
 ### Gossiping Block Node
 <aside>
-🚨 **Open Task:** Summarize initial claims and inital reasons to not support
+🚨 **Open Task:** Summarize initial claims and initial reasons to not support
 </aside>
 
 ## Open Issues