Use id instead of index

[khernyo]

It seems to me that the data referred to as index is not really an index. At least it's not the node index when building the merkle-tree. It's a bit confusing when the nodes are stored in a flat data structure (e.g., a list).

When building the merkle-tree, there is an inherent ordering which is the order in which each hash is computed (using this order requires the least amount of memory to build the merkle-tree):

1. first data block is received, its hash is computed (A)
2. second data block is received, its hash is computed (B)
3. hash of (AB) is computed (C)
4. third data block is received, hashes computed (D)
5. fourth data block is received, hashes computed (E)
6. hash of (DE) is computed (F)
7. hash of (CF) is computed (G)
   ...

The index for the above hashes in the flat-tree are the following:

• A: 0
• B: 2
• C: 1
• D: 4
• E: 6
• F: 5
• G: 3

Maybe there is a reason for using index to refer to these nodes, but I could not find one. So, if there is no specific reason for this name, I propose to use id or maybe position instead.

(Same issue in datrs: datrs/flat-tree#30)

[kasperisager]

I realise I'm late to the party but let me provide an answer for posterity: index is very much an index. Specifically, it's the index of the node in the backing array of the tree. The Merkle tree you're describing looks like this:

      G
  C       F
A   B   D   E

Notice how it's incrementally built from left to right, adding a parent node when enough children are present. The resulting array looks like this, which matches the array indices you describe:

[A, C, B, G, D, F, E]