Here's my proposal for generating fair random numbers in a distributed manner. I'll explain with a worked example with the smallest number of participants - three.
Three brothers, Jack, Bobby and Teddy agree to have a random draw to choose which one of them wins a prize, but they are in different locations.
They each create a public/private key pair and publish the public keys.
Each brother signs an agreed string with his private key, the resulting signature is his secret. The hash of the concatenated three secrets is used as a seed to generate the random number.
We want to guard against the possibility that one brother has access to the result before he has revealed his secret, enabling him to discard his secret and prevent the result from becoming known.
Round 1.
Step 1. Limited Disclosure
Jack sends his secret to Bobby. Bobby sends his secret to Teddy. Teddy sends his secret to Jack.
Step 2. Vouching
Bobby vouches that Jack has disclosed to him. Teddy vouches for Bobby. Jack vouches for Teddy.
Round 2 (Final Round for 3)
Step 1. Limited Disclosure
Jack sends his secret to Teddy. Bobby sends his secret to Jack. Teddy sends his secret to Bobby.
All three brothers now have all three secrets and can generate the random number.
Let's say Teddy waits in the final round to receive Jack's secret, generates the random number, doesn't like it and doesn't send his secret to Bobby. Bobby can always request Teddy's secret from Jack. As long as a majority are not dishonest or in collusion, the random number generated is fair, and there is no optionality problem.
For DPOS, you'd probably want to use it in combination with the existing chain of delegates - so the block would be generated first with the existing method, and then the random number is generated by N previous delegates. It should be possible to expand to N delegates, using a number of rounds of disclosure and vouching. For 101 delegates, the first round might involve each delegate disclosing to 10 other delegates, followed by vouching, followed by 10 more etc