Update Block ID & Sig calculation

tips/TIP-0046/tip-0046.md

@@ -50,22 +50,6 @@ Data types and subschemas used throughout this TIP are defined in [TIP-21](../TI
 
 This TIP uses the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash function.
 
-## Block ID
-
-A Block ID denotes an identifier of a block, with type `ByteArray[36]`. It is created from three separately spelled out
-fields due to commitment proof requirements to keep attestation proofs lightweight. It is calculated with the following
-steps:
-
-- Let `Block Header Hash` be the BLAKE2b-256 hash over the serialized block header.
-- Let `Block Hash` be the BLAKE2b-256 hash over the serialized content of the _Block_ field.
-- Let `Serialized Signature` be the serialized _Signature_.
-- Let `ID` be the BLAKE2b-256 hash of the concatenation of `Block Header Hash`, `Block Hash` and `Serialized Signature`.
-- Let `Slot Index` be the slot index of the `Issuing Time` of the block.
-- Let `Serialized Slot Index` be the little-endian serialized `Slot Index`.
-- Let `Block ID` be the concatenation of `ID` and `Serialized Slot Index`.
-
-The string format of the Block ID is the hexadecimal encoding of the `Block ID` with a `0x` prefix.
-
 ## Work Score
 
 The Work Score expresses the cost of an object in terms of computational requirements for a node to process it. It
@@ -173,9 +157,9 @@ The [_Ed25519 Signature_](../TIP-0038/tip-0038.md#ed25519-signature) is supporte
 
 The _Signature_ field over the block is computed as follows:
 
-- Let `Block Header Hash` be the BLAKE2b-256 hash over the serialized block header.
-- Let `Block Hash` be the BLAKE2b-256 hash over the serialized content of the _Block_ field.
-- Let `Signing Input` be the concatenation of `Block Header Hash` and `Block Hash`.
+- Let `Header Hash` be the BLAKE2b-256 hash over the serialized `Header`.
+- Let `Body Hash` be the BLAKE2b-256 hash over the serialized content of the `Body` field.
+- Let `Signing Input` be the concatenation of `Header Hash` and `Body Hash`.
 - Let the resulting signature be the Ed25519 signature of `Signing Input`.
 
 ### Semantic Validation
@@ -290,6 +274,22 @@ The schema of a block is as follows:
   </tr>
 </table>
 
+## Block ID
+
+A Block ID denotes an identifier of a block, with type `ByteArray[36]`. It is created from three separately spelled out
+fields due to commitment proof requirements to keep attestation proofs lightweight. It is calculated with the following
+steps:
+
+- Let `Header Hash` be the BLAKE2b-256 hash over the serialized `Header`.
+- Let `Body Hash` be the BLAKE2b-256 hash over the serialized content of the `Body` field.
+- Let `Serialized Signature` be the serialized `Signature`.
+- Let `ID` be the BLAKE2b-256 hash of the concatenation of `Header Hash`, `Body Hash` and `Serialized Signature`.
+- Let `Slot Index` be the slot index of the `Issuing Time` of the block.
+- Let `Serialized Slot Index` be the little-endian serialized `Slot Index`.
+- Let `Block ID` be the concatenation of `ID` and `Serialized Slot Index`.
+
+The string format of the Block ID is the hexadecimal encoding of the `Block ID` with a `0x` prefix.
+
 ## Basic Block
 
 ### Schema
@@ -557,15 +557,15 @@ The work score of a _Validation Block_ is `0`.
 
 **Block ID & Signature**
 
-Splitting the signing input of a Block Signature into a header and block part allows for verification of an attestation
-where only the header and block hash are known. In a similar way, a Block ID can be recomputed from an attestation
+Splitting the signing input of a Block Signature into a header and body part allows for verification of an attestation
+where only the header and body hash are known. In a similar way, a Block ID can be recomputed from an attestation
 without having the entire block.
 
 **Validation Block**
 
 The alternative could be to use a `Block` instead of `Validation Block` with some additional validation logic. However,
-having a separate block type for validator related responsibilities is much cleaner and allows for additional changes
-like allowing to reference more parents, or having specific payload types or fields in the future.
+having a separate block body type for validator related responsibilities is much cleaner and allows for additional
+changes like allowing to reference more parents, or having specific payload types or fields in the future.
 
 **Burned Mana**