Elastic and memory
This is mostly me thinking aloud, to figure this out. It's very possible that questions raised here already have answers I'm unaware of.
I've been thinking about this for a little while now, maybe someone who has a little mor insight in this can give some input on that matter. As far as i know, at the moment, elastic is essentially memory-less. This means, there are only two possible job scenarios at the moment:
Job 01 is issued. Bitcoin mining is a good example, the goal is to find a magic hash, to simplify things, lets say 8 figures long, with four zeros up front.
Miners A, B, C, D, E start working on it.
A finds 00001efg
B finds 00002ghi
C finds nothing and cancels
D finds 00003ijk
E finds 00001efg, the same as miner A (in case of finding hashes, this is highly unlikely, but depending on the specific task, this is a possible scenario.
Job 02 is issued. This time, the goal is to find a specific hash. Let's say, we try to bruteforce a password (Don't, though. This is for theories sake only). The password is "abc123".
A finds nothing and cancels
B finds "abc123" first
C finds "abc123" second
D sees that the problem is solved and cancels
E sees that the problem is solved and cancels
Without memory, these are the two types of jobs possible. but both jobs suffer from lack of memory as well, while Job 02 is a prime example for it:
If we assume, that Miners A, B, C, D and E use roughly the same approach to bruteforcing, meaning, following roughly the same iterations of figures (like trying "000001", then "000002" and so on, not that this is a good way to approach this
), this means that all of them try the same iterations, until the fastest one eventually hits the right solution. This is a giant loss of computing power. Now, in the specific scenario, the solution would be to generate random inputs, instead of following a system, but in other cases, this leads to the network as a whole computing functions, which already have a (negative) solution.
Having a memory system in place, miners could in theory write iterations they already tried in there. In practice, this works against their personal goals, because getting the job bounty is essentially a race. Thus, you'd want concurrent miners to work to as many negative iterations as possible.
What looks like a solution to this problem is to pay a bounty for every iteration computed, no matter how successful it is. However, this leads to the problem, that a Miner can intentionally hold back the correct answer to keep the job open.
If the bounty for finding the right solution is not high enough, sending negative results and getting paid for them may be more profitable than sending the solution.
If the bounty for finding the right solution is too high, sending negative results and helping other miners doing so may be not as appealing as hoping to find the right solution.
This is a messy situation. Here is an idea for a solution, though:
Pools.
I miners are organized in profit-sharing pools, they have incentive to exchange negative results with each other, because they are racing against another pool, which might win the race. In this scenario, the overall computation power would still be lowered, due to different pools competing against each other, but it would be higher than in a scenario, in which every miner is on their own.
Additionally, a scenario is possible, in which "spies" are registered in multiple pools, thus seeing the results of each other. Bit where would that lead? would that lead to Miners withholding information again? Would that lead to Miners avoiding pools? Oh, game theory, thou art a heartless bitch…
To summarize my train of thought: while it would be great to have a memory function, it may be hard to incentivise miners to use them.
This is it for now, the sun is stewing my brain. Will get back at it later.
