Distributing blocks with validation and non-dependant list generation - graph

Question

Problem
Suppose I have a system of nodes that can communicate with a parent node, but not among each other. Suppose then a file on the parent node is split up into blocks and divided among the children. The file is then deleted from the parent node.
If the parent were to then request the blocks back from the children, how can the original order be reconstructed without retaining a list of all the files on the parent. Additionally, to prevent one of the nodes from maliciously modifying a block, the parent would also have to validate the blocks coming back.
Optimal Solution
A system of naming the blocks of a file, where the list of files can be generated on any node given a seed. Given the list, a parent should be able to use the list somehow to validate the blocks coming back from children.
Attempt #1
So what I have got so far is the ability to minimally store a list of the blocks. I do so by naming the blocks as such:
block_0 = hash(file_contents)
block_n = hash(block_n-1) [hashing the name of the previous file]
This enables the order of the files to be retained by just keeping the seed (name of block_0), and the number of blocks (e.g. 5d41402abc4b2a76b9719d911017c592,5 --> seed,files). However this will not allow the files to be validated independently.
Attempt #2
Simply take the hash of each block and store that in a list. However this is not efficient and will result in a large amount of memory allocated to this task alone if a large number of blocks need to be tracked. This will not do.

Answer 1

I'm not sure if I've got the problem, but I guess this is a possible solution:
| Distribution:
parent | buffer = [hash(key, id)), data[id]]; send(buffer);
nodes | recv(buffer); h_id, data = buffer;
The parent node uses some local key to generate a hashed value (h_id) to the id part of data it is sending, and the local nodes will receive both the resulting h_id and the data itself.
| Reduction:
nodes | buffer = [h_id, data]; send(buffer);
parent | recv(buffer); h_id, data_id = buffer;
On the counter flow, the nodes must send both the original h_id and the data formerly received, otherwise, the following verification will fail:
hash(key, data) == h_id
Since key is only known in the parent node, it would be hard for the local nodes to alter data and h_id in such a way that hash(key, data_id), in the parent node, would still be valid.
Concerning the ordering, you could simply assume that the four initial bytes of data store the number of the partition -- for later reconstruction.
Edit:
I may have not noticed this extra storage you pointed, but here is what I've tried to propose. Consider four machines, A, B, C, and P, with the initial data:
P{key, data[3]}
____|____
/ | \
A{} B{} C{}
Then, P distributes the data among the machines, sending both the data shard itself, and the generated hash:
P{key, data[3]}
____|____
/ | \
A | C
{data[0], hash(key, data[0])} | {data[2], hash(key, data[2])}
B
{data[1], hash(key, data[1])}
If you assume the first bytes in data[i] store a global index, you're able to rebuild the initial base data[3] in the original order. Also, if you allow each machine to store/receive key, you'll be able to later un hash data[i] and rebuild data[3] on every local node.
Notice the addition of errors can only take place over the shards of data data[i], and over the received key hash(key, data[i]), as you must assume key to be globally valid. The main point here is that the list of hash(key, data[i]) values are also distributed among the machines, not only the data partitions themselves, i.e., you need no list with all files to be stored in any machine alone.
Considering you can afford to maintain key in every node, or at least to send key to the one node trying to rebuild the original data, here goes an example of a reduction step, say, for node B. A and C send their local {data[i], hash(key, data[i])} to node B, and P sends key to B, so this node can un hash the received data:
P{key, data[3]}
|
A | C
{data[0], hash(key, data[0])} | {data[0], hash(key, data[0])}
\ | /
B
{data[1], hash(key, data[1])}
Then, B computes:
/ {data[1], hash(key, data[1])} \ {data[1]}
unhash( {data[0], hash(key, data[0])} ) => {data[0]} => {data[3]}
\ {data[2], hash(key, data[2])} / {data[2]}
Which restores the original data with the correct ordering.