Cleaned up and added protobuf assets

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

Author: Nana-EC

HIP/hip-1081.md

@@ -1,14 +1,14 @@
 ---
 hip: 1081
 title: Block Node
-author: Nana Essilfie-Conduah <@Nana-EC>, Jasper Potts <@jasperpotts>, Richard Bair <@rbair>,
+author: Jasper Potts <@jasperpotts>, Richard Bair <@rbair>, Nana Essilfie-Conduah <@Nana-EC>,
 Joseph Sinclair<@jsync-swirlds>
-working-group: Richard Bair <@rbair>, Anurag Saksena, Mark Blackman <mark@swirldslabs.com>,
-Matt Peterson <@mattp-swirldslabs>, Alfredo Gutierrez <@AlfredoG87>, Georgi Lazarov <@georgi-l95>,
-Nick Poorman <@nickpoorman>
+working-group: Jasper Potts <@jasperpotts>, Richard Bair <@rbair>, Nana Essilfie-Conduah <@Nana-EC>,
+Anurag Saksena <@a-saksena>, Mark Blackman <mark@swirldslabs.com>, Matt Peterson <@mattp-swirldslabs>,
+Alfredo Gutierrez <@AlfredoG87>, Georgi Lazarov <@georgi-l95>, Nick Poorman <@nickpoorman>
 requested-by: Hedera Consensus Node Operators, Cosmic Wire, Limechain
 type: Standards Track
-category: Service, Mirror, Block Node
+category: Service, Mirror, Block
 needs-council-approval: Yes
 status: Draft
 created: 2024-05-15
@@ -32,6 +32,11 @@ Block Nodes will have a rich API, allowing consumers to receive a subset of the
 can innovate on payment -- they can be commercial and have connectivity rules / rate limits / SLAs for customers. 
 They can require payment for serving blocks, or they can serve blocks for free.
 
+Block nodes will supersede the cloud storage buckets utilized today. Besides taking over storage duties, block nodes
+will also offer reconnection services to consensus nodes and provide cryptographic proofs to both users and mirror
+nodes, enhancing the system's security and decentralization.
+Mirror nodes will be updated to be able to retrieve block streams directly from block nodes.
+
 ## Motivation
 
 In the current network architecture the consensus node outputs data representing snippets of consensus and transaction
@@ -62,6 +67,8 @@ As such consumers will utilzie 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.
 
+
+
 <aside>
 🚨 **Open Task:** Flesh out design decisions approach
 </aside>
@@ -71,6 +78,20 @@ In the future it may be valuable to explore and add additonal protocol such as W
 Highlight CN(s) -> BN -> MN + block stream clients
 </aside>
 
+
+### 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
+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
+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.
+
+The block node will support semantic version values and will make it's current version available via API requests.
+
 ## User stories
 
 ### Personas
@@ -148,9 +169,14 @@ in the [hedera-protobuf repository](https://github.com/hashgraph/hedera-protobuf
 
 ### Services
 To achieve the above the block node will offer multiple pluggable modular services which can be enabled by node operators.
+Note: protobuf summaries are noted in this HIP doc. The full protobuf specification can be found under
+[block node protobuf](./../assets/hip-1081/protobuf)
 
 #### Block Node Service
-The block node service will provide ancillary services to inform users of node readiness and configuration
+The block node service will provide ancillary services to inform users of node readiness and configuration.
+
+The `serverStatus` endpoint will provide consumers with details around block ranges, node version and if historical
+snapshots are supported.
 
 ```protobuf
 /**
@@ -174,10 +200,12 @@ There will be 2 types of stream services offered
 - Unverified block stream for low latency
 - Verified block stream for high confidence
 
-Depending on a user of tools needs they can optimize for requesting Block Items as fast as possible for their own
+Depending on a user, consuming clients can optimize for requesting Block Items as fast as possible for their own
 optional verification or rely on confirmed blocks as confirmed by a Block Node following the Block Proof algorithm.
 
 Both streams may also offer filtering capabilities based on user requests and Block Node functionality support.
+Filtering support is expanded upon in the Block Stream HIP 1056 and is charectorized buy the replacement of block items
+with hash values whiles maintian the ability to carry out block and state proofs on the block information.
 
 Initially filtering will be at the Block Item level (e.g. a Mirror Node may want only Transaction input and outputs)
 but in the future block nodes could stream blockItems out based on the matching of state or transaction matches.
@@ -206,6 +234,7 @@ This approach can be used to increase the reliability and availability of networ
 
 As the block stream is ongoing and items are sent out in real time, it is valuable to be able to request a historical
 block in its entirety.
+The `singleBlock` endpoint will allow a consumer to request a single verified block from the block node.
 
 ```protobuf
 /**
@@ -237,16 +266,23 @@ service StateService {
 ```
 
 <aside>
-🚨 **Open Task:** Flesh out 4 different state related query endpoints
-1. Live state querying i.e. what is the latest state
-2. Historical state snapshot e.g. what was state at block number x
-3. 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
-4. Single entity state query e.g. return account 0.0.x 
-
+🚨 **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
+  - 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
-Support CN connecting to BN to be taught about latest stake instead of another CN
+
+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.
+
+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.
 
 <aside>
 🚨 **Open Task:** Expand
@@ -256,6 +292,11 @@ Support CN connecting to BN to be taught about latest stake instead of another C
 </aside>
 
 #### 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
+a block node can finally fill this gap and provide users with proofs including that of state.
+
 <aside>
 🚨 **Open Task:** Flesh out repsonse components
 Noting the 3 different proof types
@@ -265,16 +306,23 @@ Noting the 3 different proof types
 </aside>
 
 ### Discovery
+
+To ensure a robust decentralized network it is improtant for block nodes to be easily discovered by clients.
+
 <aside>
-🚨 **Open Task:** Explain how block nodes are discovered
+🚨 **Open Task:** Explain how block nodes provide discovery details. 
+Cosniderations
+- Are they self reported?
+- Are they onchain?
+- What requirements if any are there for a block node and operator?
+</aside>
 
+<aside>
+🚨 **Open Task:** Explain how block nodes are discovered
 - by a client so they can query data
 - by a CN so they can push data e.g. by address book
-
 </aside>
 
-### Upgradeability
-
 
 ### Monetization
 
@@ -371,11 +419,10 @@ a Block.
 
 ## Open Issues
 
-1. Q: “As a block node operator I should be able to attach custom plugins to the block node, which can utilize its
-functionality.” was previously listed as a user story. Is this an intent to be highlighted?
-    1. [Ans]
-2. Q: Do we want to highlight anonymous node runners?
-3. Q: Does the block node require or rely on a transmission of full state from a CN? If so what’s the contract between
+- [ ] Q: “As a block node operator I should be able to attach custom plugins to the block node, which can utilize its
+    functionality.” How should this intent be highlighted in specification. Are the detail more implementation and future
+    expansions that should be captured in separate HIPs and product EPICs?
+- [ ] Q: Does the block node require or rely on a transmission of full state from a CN? If so what’s the contract between
 nodes here? Previously the CN output state every 15 mins
 
 ## References