Some people are working on that. The hard part is how to get the right result on chain.
@vbuterin proposal is a really good idea but had some flows, it required computing the sequential hashes for each submitter, therefore requiring each participant to have one cpu per participant which would not scale well.
We can solve this by having the seed=hash(x1,x2,…,xn) in whatever order. Parties can change the seed, but cannot set it to a particular value due to preimage resistance.
An article about sequential hashing (and also modular squaring) has been published http://stevengoldfeder.com/papers/BGB17-IEEESB-proof_of_delay_ethereum.pdf , only using the blockhash as a seed (which is sufficient in PoW, as miners can withhold blocks with blockhash they don’t like, but can’t set it to a particular value) but we still need a full implementation and this proposal is vulnerable to the delay attack.
You can look at Multiparty Interactive Verification for discussions about how to verify it while mitigation the delay attack.
RNG is really important both for protocols and apps. The RNG proposal of the yellow paper (using a low influence function) is IMO quite week as parties can collude to control it (by inputting non random values always biased in the same direction, I mean if a minority collude inputting the same number, if the other parties don’t collude and give random values, the bit to bit vote will what colluders decided with high probability). What RNG does the fondation plan to use for POS?