Protocol-level randomness for SCP nomination, transaction application ordering, and Soroban PRNG

[EslaM-X]

Problem

Stellar currently derives randomness used by several protocol components
from values that can be influenced by the consensus process.

This raises a broader protocol question:

Should Stellar have a protocol-level source of unpredictable,
bias-resistant randomness, and if so, what guarantees should that source
provide to each consumer?

Consumers being investigated

The three potential consumers I am currently investigating are:

• SCP nomination / leader selection
• transaction application ordering
• Soroban PRNG

Where this stands

I initially explored a VRF-based shared randomness construction.
After extensive adversarial modeling, however, it became clear that these
consumers have different lock/reveal and liveness requirements.

So I would like to discuss the protocol requirements first rather than
proposing the current implementation as the solution.

Questions I'd like to get feedback on

1. Is protocol-level randomness actually a desirable primitive for Stellar,
   or should these use cases remain separate?
2. Which of the three consumers, if any, actually require unpredictability /
   bias resistance at the protocol level?
3. What should the lock/reveal contract be for each consumer?
4. Should a common randomness source be shared between consumers, or should
   each consumer have an independent construction?
5. What liveness guarantees should a protocol randomness primitive be required
   to provide under SCP's local quorum topology?
6. What is the simplest design that provides the required guarantees without
   introducing unnecessary consensus complexity?