renames OMT to HMMT

rln-research/membership-merkle-tree-storage-evaluation.md

@@ -1,14 +1,14 @@
 # Waku-RLN-Relay: Evaluating Storage Overhead of Membership Merkle Tree   
 ## Introduction
 
-In the current design of the Waku-RLN-Relay protocol, the membership Merkle tree (MT) is locally persisted by all peers being relayer or message publisher. Message publishers require the MT to be able to generate valid proofs with respect to the latest state of the membership group whereas the relayers need the knowledge of MT to be able to verify the rate-limit proofs of the Waku messages. This incurs some storage overhead which may or may not fit resource-limited devices. This overhead also depends on the algorithm used to represent the Merkle tree. So far, we are aware of two algorithms namely, Full Merkle tree (FMT) and Optimal Merkle tree (OMT), and in this post, we would like
+In the current design of the Waku-RLN-Relay protocol, the membership Merkle tree (MT) is locally persisted by all peers being relayer or message publisher. Message publishers require the MT to be able to generate valid proofs with respect to the latest state of the membership group whereas the relayers need the knowledge of MT to be able to verify the rate-limit proofs of the Waku messages. This incurs some storage overhead which may or may not fit resource-limited devices. This overhead also depends on the algorithm used to represent the Merkle tree. So far, we are aware of two algorithms namely, Full Merkle tree (FMT) and Hash-Map Merkle tree (HMMT), and in this post, we would like
 1) to compare the two existing MT algorithms and clarify their differences in terms of storage requirements.
 2) to determine whether the storage overhead of the membership MT fits the resource-limited devices. 
 3) depending on the second item, then we can decide on whether more research on the MT storage optimization is required or not.
 
 **Existing Merkle tree algorithms**: In the present post, we analyze two different MT algorithms:
 - Full Merkle tree (FMT): in this algorithm, an empty full tree with a specific depth is being initialized and the required memory space is allocated upfront. The values of the existing nodes are altered as new nodes are added to the tree.
-- Optimal Merkle tree (OMT): In this algorithm, which is implemented in the  [killic library](https://github.com/status-im/rln/blob/master/src/merkle.rs), the Merkle tree nodes are generated incrementally as new leaves are being added to the tree.
+- Hash-Map Merkle tree (HMMT): In this algorithm, which is implemented in the  [killic library](https://github.com/status-im/rln/blob/master/src/merkle.rs), the Merkle tree nodes are generated incrementally as new leaves are being added to the tree.
 
 ## Storage Overhead Analysis
  
@@ -41,15 +41,15 @@ The FMT algorithm uses an array with `2*(2^d)-1` entries to represent a Merkle t
 **Group size < Tree capacity**: In FMT, the group size does not affect the storage overhead because the required space for the full tree is allocated at the beginning; further updates on the tree only alter the existing values.  For example, at `d=20`, the storage overhead is `67` MB even if the current group size is `1000`. 
 Therefore, in the FMT algorithm,  it is best to set the tree depth close to the expected group size to save storage space.
 
-### Optimal Merkle Tree Algorithm (OMT)
+### Optimal Merkle Tree Algorithm (HMMT)
 In this algorithm, each Merkle tree node is indexed by two values each of size `8` bytes on a 64-bit machine (`4` bytes on a 32-bit machine). As such, each tree node takes up `2*8 +32 = 48` bytes corresponding to the size of indices and the hash output.
 
 **Group size = Tree capacity** The following figure demonstrates the maximum storage overhead (i.e., when group size is equal to tree capacity) over varying tree depths i.e., `d=[1..20]`. 
-![OMT max](https://i.imgur.com/dm4vEvQ.png)
+![HMMT max](https://i.imgur.com/dm4vEvQ.png)
 
 
 **Group size < Tree capacity**
-In the OMT algorithm, a hash-map is used to instantiate a Merkle tree. Nodes are added to this map gradually as new leaves are added to the tree. Each MT node encapsulates a 32-byte hash value and index of size `16` bytes.  
+In the HMMT algorithm, a hash-map is used to instantiate a Merkle tree. Nodes are added to this map gradually as new leaves are added to the tree. Each MT node encapsulates a 32-byte hash value and index of size `16` bytes.  
 Unlike FMT, since space allocation is done incrementally, the storage overhead is a function of the group size and is less affected by the tree depth. Below, we demonstrate this fact for a tree with a depth of `20`. Under this depth, for a group size of `1000`, the storage overhead is `0.097` MB which is almost `1000` times less than the storage overhead of a full tree with depth `20` i.e., `100` MB.
 ![](https://i.imgur.com/l5xNMqN.png)
 
@@ -70,17 +70,17 @@ Note that this analysis is only valid for the storage overhead, however, setting
 
 
 
-### FMT vs OMT
+### FMT vs HMMT
 
-Comparing the max storage overhead of FMT and OMT, as depicted in the figure below, brings us to the conclusion that FMT is more efficient than OMT. However, this is only true for the worst-case scenario where the group is full to the maximum tree capacity.
-![Max relative](https://i.imgur.com/G8COahY.png)
+Comparing the max storage overhead of FMT and HMMT, as depicted in the figure below, brings us to the conclusion that FMT is more efficient than HMMT. However, this is only true for the worst-case scenario where the group is full to the maximum tree capacity.
+![Max relative](pics/max-storage-fmt-hmmt.png)
 
-But, this worst-case scenario does not always hold, instead, in most states of the system, the group size is much less than the tree capacity. In the following figure, we take a snapshot of the system at group size `1000`. In this snapshot, we compare the storage overhead incurred by FMT and OMT for `d=[10..20]`.
-![group 1000](pics/fmt-vs-omt-g-1000.png)
+But, this worst-case scenario does not always hold, instead, in most states of the system, the group size is much less than the tree capacity. In the following figure, we take a snapshot of the system at group size `1000`. In this snapshot, we compare the storage overhead incurred by FMT and HMMT for `d=[10..20]`.
+![group 1000](pics/fmt-vs-HMMT-g-1000.png)
 
-As you can see, in this more realistic scenario, OMT shows better performance than FMT. For example, for `d=20`, persisting a group of `1000` members using OMT requires  `0.097 MB` whereas it requires `67.1 MB` when using FMT, which is `700` times more than OMT.
+As you can see, in this more realistic scenario, HMMT shows better performance than FMT. For example, for `d=20`, persisting a group of `1000` members using HMMT requires  `0.097 MB` whereas it requires `67.1 MB` when using FMT, which is `700` times more than HMMT.
 
-It brings us to another conclusion that OMT outperforms FMT when group size is less than the tree capacity. However, the exact point at which this relationship changed needs more investigation.
+It brings us to another conclusion that HMMT outperforms FMT when group size is less than the tree capacity. However, the exact point at which this relationship changed needs more investigation.
 
 
 
@@ -93,11 +93,11 @@ It brings us to another conclusion that OMT outperforms FMT when group size is l
 | Algorithm\Tree depth | d=10      | d=20      |
 | -------------------- | --------- | --------- |
 | FMT                  | 0.065  MB | 67.10 MB  |
-| OMT                  | 0.098  MB | 100.66 MB |
+| HMMT                  | 0.098  MB | 100.66 MB |
 
 However, the MT storage overhead may not be reasonable for mobile devices especially if we plan to load the MT in memory in which case we will/may face the per-app memory cap of `32 MB` on Android phones.
 
-2) If we can not predict the maximum group size (hence the max tree depth), then it is more efficient to use the OMT algorithm. This is because the storage overhead of OMT is proportional to the group size and less affected by the tree depth.  For instance, consider a tree with a depth of `20` and with `1000` active leaves. MT storage using OMT requires  `0.097 MB` whereas  `67.1 MB` when using FMT, `700` times more than OMT.  However, the exact point at which this relationship may change needs more investigation.
+2) If we can not predict the maximum group size (hence the max tree depth), then it is more efficient to use the HMMT algorithm. This is because the storage overhead of HMMT is proportional to the group size and less affected by the tree depth.  For instance, consider a tree with a depth of `20` and with `1000` active leaves. MT storage using HMMT requires  `0.097 MB` whereas  `67.1 MB` when using FMT, `700` times more than HMMT.  However, the exact point at which this relationship may change needs more investigation.
 3) If the maximum group size is known, then it would be more efficient to use FMT.