Verify product without revealing multipliers Situation:

Several participants contribute encrypted random numbers. These numbers will be used to generate community-agreed random (by simple multiplication).

Question:

Is there any way to detect same products values without revealing multipliers? Maybe it is possible to use some homomorphic encryption?

What I originally want to do:
The task is do eliminate same random values (results), generated in different rounds. There should be some history log and we should regenerate random result if we already generated equal one.
You are asking the wrong question.  You shouldn't do it the way you described (by multiplying or adding random numbers submitted by the participants).  This problem has been well-studied, and there are solutions to it.  Your question assumes a particular approach to the problem, but that approach turns out to be flawed.

Your approach is vulnerable to numerous security problems.  For instance, if you multiply, any one participant can force the final result to be 0 by just submitting 0 as their contribution.  As another example, if you add, any one participant can force the final result to be anything they want, by waiting for everyone else to submit their contributions, looking at their contributions, and then choosing their own contribution so they all sum to the desired result.

Instead, if you want to jointly generate a community random value that none of you can influence, here is what you should do:


Each party picks a random value, and publicly commits to it.  In detail: the party Pi should pick a 128-bit random value ri and broadcast yi = Hash(ri, Pi).
After everyone has received everyone else's commitments (yi values), then each party should open their commitment.  In detail: once party Pi has received all n-1 commitments, he/she broadcasts ri.  Everyone checks that each published ri value is consistent with the earlier commitment yi.  If anyone detects any inconsistency, or if anyone doesn't finish the protocol, you have to call the whole thing off and punish whoever didn't follow the instructions.
Finally, compute R = Hash(r1, r2, ..., rn).  The value R is the random value that everyone has jointly generated.


The security property we get is that no one party, or no coalition of a subset of the parties, can influence the final random number R, except by refusing to finish the protocol.

(You'll have to have a separate out-of-band way to punish parties who don't follow instructions or don't finish the protocol.  The scheme above describes how to detect such parties; it will be up to you to adequately disincentivize such behavior.  If a malicious party Pj is willing to possibly decline to finish the protocol, they can exert modest influence over the final random number R, simply by waiting to be last to reveal their random number rj, checking what R would be if they finished the protocol, and determining whether it is more favorable to them to finish the protocol and end with random number R or to refuse to finish the protocol and leave everyone with no random number.)