fix: standardize SHA/Sha formatting

foundations/whitepapers/tblkch.mdx

@@ -59,21 +59,21 @@ where $[A]$ equals one when condition $A$ is true, and zero otherwise.
 
 - Next, $\lceil l/8\rceil$ data bytes follow. This means that the $l$ data bits of the cell are split into groups of eight, and each group is interpreted as a big-endian 8-bit integer and stored into a byte. If $l$ is not divisible by eight, a single binary one and a suitable number of binary zeroes (up to six) are appended to the data bits, and the completion tag (the least significant bit of the descriptor byte $d_2$) is set.
 
-- Finally, $r$ references to other cells follow. Each reference is normally represented by 32 bytes containing the $\text{Sha256}$ hash of the referenced cell, computed as explained below in [1.1.4](#1-1-4-the-sha256-hash-of-a-cell).
+- Finally, $r$ references to other cells follow. Each reference is normally represented by 32 bytes containing the SHA-256 hash of the referenced cell, computed as explained below in [1.1.4](#1-1-4-the-sha256-hash-of-a-cell).
 
 In this way, the standard representation $\text{CellRepr}(c)$ of a cell $c$ with $l$ data bits and $r$ references is $2+\lceil l/8\rceil+32r$ bytes long.
 
-### 1.1.4. The Sha256 hash of a cell
+### 1.1.4. The SHA-256 hash of a cell
 
-The $\text{Sha256}$ hash of a cell $c$ is recursively defined as the $\text{Sha256}$ of the standard representation $\text{CellRepr}(c)$ of the cell in question:
+The SHA-256 hash of a cell $c$ is recursively defined as the SHA-256 of the standard representation $\text{CellRepr}(c)$ of the cell in question:
 
 $$
 \text{Hash}(c):=\text{Sha256}(c):=\text{Sha256}\bigl(\text{CellRepr}(c)\bigr) \tag{2}
 $$
 
-Because cyclic cell references are not allowed (the relationships among all cells must constitute a directed acyclic graph, or DAG), the $\text{Sha256}$ hash of a cell is always well-defined.
+Because cyclic cell references are not allowed (the relationships among all cells must constitute a directed acyclic graph, or DAG), the SHA-256 hash of a cell is always well-defined.
 
-Furthermore, because $\text{Sha256}$ is tacitly assumed to be collision-resistant, we assume that all the cells that we encounter are completely determined by their hashes. In particular, the cell references of a cell $c$ are completely determined by the hashes of the referenced cells, contained in the standard representation $\text{CellRepr}(c)$.
+Furthermore, because SHA-256 is tacitly assumed to be collision-resistant, we assume that all the cells that we encounter are completely determined by their hashes. In particular, the cell references of a cell $c$ are completely determined by the hashes of the referenced cells, contained in the standard representation $\text{CellRepr}(c)$.
 
 ### 1.1.5. Exotic cells
 
@@ -350,7 +350,7 @@ Notice that on some occasions Merkle proofs must be embedded into the block itse
 
 ### 1.3.20. Provisions for handling incomplete data
 
-As we have seen, it is necessary to include incomplete data and Merkle proofs into the body of a block, into the body of some messages contained in a block, and into the state. This necessity is reflected by some extra representation conditions, as well as provisions for the messages (and by extension, the cell trees processed by TVM) to contain incomplete data (external cell references and Merkle proofs). In most cases, such external cell references contain only the 256-bit $\texttt{Sha256}$ hash of a cell along with a flag; if a smart contract attempts to inspect the contents of such a cell by a $\texttt{CTOS}$ primitive (e.g., for deserialization), an exception is triggered. However, an external reference to such a cell can be stored into the smart contract's persistent storage, and both the transparent and the representation hashes of such a cell can be computed.
+As we have seen, it is necessary to include incomplete data and Merkle proofs into the body of a block, into the body of some messages contained in a block, and into the state. This necessity is reflected by some extra representation conditions, as well as provisions for the messages (and by extension, the cell trees processed by TVM) to contain incomplete data (external cell references and Merkle proofs). In most cases, such external cell references contain only the 256-bit SHA-256 hash of a cell along with a flag; if a smart contract attempts to inspect the contents of such a cell by a $\texttt{CTOS}$ primitive (e.g., for deserialization), an exception is triggered. However, an external reference to such a cell can be stored into the smart contract's persistent storage, and both the transparent and the representation hashes of such a cell can be computed.
 
 ---
 
@@ -734,7 +734,7 @@ This section exposes the details of the hypercube routing protocol employed by t
 
 ### 2.2.1. Message uniqueness
 
-Before continuing, let us observe that any (internal) message is *unique*. Recall that a message contains its full source address along with its logical creation time, and all outbound messages created by the same smart contract have strictly increasing logical creation times (cf. [1.4.6](#1-4-6-logical-time-in-the-ton-blockchain)); therefore, the combination of the full source address and the logical creation time uniquely defines the message. Since we assume the chosen hash function $\text{Sha256}$ to be collision resistant, *a message is uniquely determined by its hash*, so we can identify two messages if we know that their hashes coincide.
+Before continuing, let us observe that any (internal) message is *unique*. Recall that a message contains its full source address along with its logical creation time, and all outbound messages created by the same smart contract have strictly increasing logical creation times (cf. [1.4.6](#1-4-6-logical-time-in-the-ton-blockchain)); therefore, the combination of the full source address and the logical creation time uniquely defines the message. Since we assume the chosen hash function SHA-256 to be collision resistant, *a message is uniquely determined by its hash*, so we can identify two messages if we know that their hashes coincide.
 
 This does not extend to external messages "from nowhere", which have no source addresses. Special care must be taken to prevent replay attacks related to such messages, especially by designers of user wallet smart contracts. One possible solution is to include a sequence number in the body of such messages, and keep the count of external messages already processed inside the smart-contract persistent data, refusing to process an external message if its sequence number differs from this count.
 
@@ -2034,7 +2034,7 @@ signed_block block:^Block blk_serialize_hash:uint256
   = SignedBlock;
 ```
 
-The *serialization hash* `blk_serialize_hash` of the unsigned block `block` is essentially a hash of a specific serialization of the block into an octet string (cf. [5.3.12](#5-3-12-the-serialization-hash-of-a-block) for a more detailed explanation). The signatures collected in `signatures` are Ed25519-signatures (cf. [A.3](#a-3-ed25519-cryptography)) made with a validator's private keys of the $\text{Sha256}$ of the concatenation of the 256-bit representation hash of the block `block` and of its 256-bit serialization hash `blk_serialize_hash`. The 64-bit keys in dictionary `signatures` represent the first 64 bits of the public keys of the corresponding validators.
+The *serialization hash* `blk_serialize_hash` of the unsigned block `block` is essentially a hash of a specific serialization of the block into an octet string (cf. [5.3.12](#5-3-12-the-serialization-hash-of-a-block) for a more detailed explanation). The signatures collected in `signatures` are Ed25519-signatures (cf. [A.3](#a-3-ed25519-cryptography)) made with a validator's private keys of the SHA-256 of the concatenation of the 256-bit representation hash of the block `block` and of its 256-bit serialization hash `blk_serialize_hash`. The 64-bit keys in dictionary `signatures` represent the first 64 bits of the public keys of the corresponding validators.
 
 ### 5.1.9. Serialization of a signed block
 
@@ -2045,7 +2045,7 @@ The overall procedure of serializing and signing a block may be described as fol
 2. Validators sign the 256-bit combined hash
 
    $$
-   H_B:=\text{sha256}\bigl(\text{Hash}_\infty(B).\text{Hash}_M(S_B)\bigr) \tag{18}
+   H_B:=\text{Sha256}\bigl(\text{Hash}_\infty(B).\text{Hash}_M(S_B)\bigr) \tag{18}
    $$
 
    of the representation hash of $B$ and of the Merkle hash of its serialization $S_B$.
@@ -2291,7 +2291,7 @@ Then a compiled smart contract may be represented by a value of type *CompiledSm
 
 On some occasions, we must define a Merkle hash $\text{Hash}_M(s)$ of an arbitrary octet string $s$ of length $|s|$. We do this as follows:
 
-- If $|s|\leq 256$ octets, then the Merkle hash of $s$ is just its $\text{Sha256}$:
+- If $|s|\leq 256$ octets, then the Merkle hash of $s$ is just its SHA-256:
 
 $$
 \text{Hash}_M(s):=\text{Sha256}(s)\quad\text{if }|s|\leq 256. \tag{19}
@@ -2303,9 +2303,9 @@ $$
 \text{Hash}_M(s):=\text{Sha256}\bigl(\text{Int}_{64}(|s|).\text{Hash}_M(s').\text{Hash}_M(s'')\bigr) \tag{20}
 $$
 
-In other words, we concatenate the 64-bit big-endian representation of $|s|$ and the recursively computed Merkle hashes of $s'$ and $s''$, and compute $\text{Sha256}$ of the resulting string.
+In other words, we concatenate the 64-bit big-endian representation of $|s|$ and the recursively computed Merkle hashes of $s'$ and $s''$, and compute SHA-256 of the resulting string.
 
-One can check that $\text{Hash}_M(s)=\text{Hash}_M(t)$ for octet strings $s$ and $t$ of length less than $2^{64}-2^{56}$ implies $s=t$ unless a hash collision for $\text{Sha256}$ has been found.
+One can check that $\text{Hash}_M(s)=\text{Hash}_M(t)$ for octet strings $s$ and $t$ of length less than $2^{64}-2^{56}$ implies $s=t$ unless a hash collision for SHA-256 has been found.
 
 ### 5.3.12. The serialization hash of a block