Cleaned up platform related proto

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

HIP/hip-1056.md

@@ -579,18 +579,17 @@ node software.
 
 ```protobuf
 message EventTransaction {
-  oneof transaction {
-    /**
-    * SignedTransaction serialized into bytes.
-    * SignedTransaction is specified by the existing HAPI API.
-    */
-    bytes signed_transaction_bytes = 1;
+    oneof transaction {
+        /**
+         * An application transaction.
+         */
+        bytes application_transaction = 1;
 
-    /**
-    * A single state signature.
-    */
-    StateSignatureSystemTransaction state_signature = 2;
-  }
+        /**
+         * A single state signature.
+         */
+        StateSignatureSystemTransaction state_signature_transaction = 2;
+    }
 }
 ```
 
@@ -885,21 +884,21 @@ for accounts with large numbers of keys like those owned by the council. We have
 
 ```protobuf
 message StateChanges {
-  /**
-  * The consensus timestamp of this set of changes.
-  * See the full specification above for how this value is determined.
-  * <p>
-  * This value SHALL be deterministic.
-  */
-  proto.Timestamp consensus_timestamp = 1;
+    /**
+     * The consensus timestamp of this set of changes.
+     * See the full specification above for how this value is determined.
+     * <p>
+     * This value SHALL be deterministic.
+     */
+    proto.Timestamp consensus_timestamp = 1;
 
-  /**
-  * An ordered list of individual changes.
-  * <p>
-  * These changes MUST be applied in the order listed to produce
-  * a correct modified state.
-  */
-  repeated StateChange state_changes = 2;
+    /**
+     * An ordered list of individual changes.
+     * <p>
+     * These changes MUST be applied in the order listed to produce
+     * a correct modified state.
+     */
+    repeated StateChange state_changes = 2;
 }
 ```
 
@@ -1140,67 +1139,6 @@ message MapUpdateChange {
 }
 ```
 
-Possible items for splitting Account messages to reduce the need to duplicate very large key sets on every balance
-change.
-
-```protobuf
-// NOTES BELOW ARE NOT FINAL:
-
-// Option 3, Alternative 1
-// modify the MapUpdateChange to support a partial change value
-message MapUpdateChange {
-  MapChangeKey key = 1;
-  oneof {
-    MapChangeValue value = 2;
-    MapChangePartialValue value = 2;
-  }
-}
-
-// Ordinal is part of the merkle key for the sub-tree
-// only send the one part that is needed, to update both send two map update changes.
-// This is added to the `MapUpdateChange` message.
-message MapChangePartialValue {
-  uint32 partOrdinal = 1;
-  oneof account_parts {
-    AccountPartA account_part_a = 2;
-    AccountPartB account_part_b = 3;
-  }
-}
-
-// Option 3, Alternative 2
-// Similar to `MapPartialValue`, but at the `MapChangeValue` level where we already have many fields, instead
-// of adding a completely divergent field to `MapUpdateChange` and adding complexity there
-message MapChangeValue {
-  ...
-  AccountChange account_change = 14;
-}
-
-// Use this account change entry, and only set the part that changed.
-// Changing both parts requires two account change block items.
-message AccountChange {
-  oneof account_parts {
-    AccountPartA account_part_a = 1;
-    AccountPartB account_part_b = 2;
-  }
-  // This may or may not be needed, depending on how the account is stored in state
-  uint32 partOrdinal = 3;
-}
-////////// End Option 3 //////////
-
-// Option 4, use a single message with two sub-messages in state **and** in the block stream
-// Recipients must check presence (e.g. accountValue.isAccountPartBSet() ) and fill in any un-set sub-message from prior state if needed.
-message Account {
-  optional AccountPartA account_part_a = 1;
-  optional AccountPartB account_part_b = 2;
-}
-////////// End Option 4 //////////
-
-// Both Option 3 and Option 4 use these two sub-messages.
-message AccountPartA {}
-message AccountPartB {}
-
-```
-
 ```protobuf
 /**
  * A removal of a single item from a `VirtualMap`.
@@ -1984,7 +1922,7 @@ Open Issues captured here and in https://github.com/hashgraph/hedera-block-node/
       block size and avoid adopting an entity state changes splitting strategy?
 - [ ] Q: Are there additional protocol buffer changes needed to reduce the
       stream overhead for Events, Transactions, or other frequent entities.      
-- [ ] Q: Is it clear which block contains a block proof and state hash regarding
+- [x] Q: Is it clear which block contains a block proof and state hash regarding
       that block?
    - A block will contain it's own proof. The state hash a block contains
      however is the hash at the begining of the block/end of the previous block.