Practical Time-lock encryption.

[ple1n]

https://drand.love/blog/2023/03/28/timelock-on-fastnet/
https://github.com/drand/tlock/

It can be readily applied to Locutus,

• Time-locked forum upvotes. Compared to commitment schemes, it doesn't need a reveal step performed by the voter. Hiding upvote/downvotes for a fixed period of time can mitigate the echo-chamber effect.
  • Time-lock-encrypted, ZKP-anonymous polls
• Indistinguishable contract deltas. One connects to a few nodes to publish contract deltas, it's possible that they selectively censor the delta, refusing to pass them to other nodes. The proposed uniform deltas only show proofs enough to pass contract verification, and nothing else. Note that nodes can always remove undesired data later, but they can not selectively curb delta propagation.
  • Nodes may outright delay/censor all encrypted deltas
  • Alternative: publish delta to more nodes

[sanity]

I think something like this could be done in a completely decentralized way on Locutus. This is far from complete and just the result of a few minutes' brainstorming:

Early thoughts on a Public Verifiable Random Number Generator (PVRNG) on the Locutus Decentralized P2P Network

Objective:

To develop a decentralized, public, and verifiable random number generator on the Locutus network. The system aims to be robust, secure, resilient, and minimize trust requirements. The participants in the system are called "seeders".

Proposal Overview:

1. Seeder Selection: Use a reputation system to establish seeder eligibility. This system should minimize the risk of collusion and fraud by increasing the cost associated with sybil attacks. It should promote a diverse set of participants and provide clear incentives for participation and penalties for misbehavior.

2. Selector Generation: Generate a set of "selector" locations deterministically for each 10-minute epoch on a 1D ring between 0.0 and 1.0. These locations are generated from the hash of the previous random number and the epoch timestamp. The closer a seeder's location (derived from the hash of their public key) is to any selector for a given epoch, the higher their priority.

3. Seed Submission and Collection: Each eligible seeder submits their "seed," a signed version of the epoch timestamp. A smart contract collects these seeds for the epoch, retaining the closest N seeds from the seeders closest to the selector locations. The seed collection process occurs within the first 9 minutes of the 10-minute epoch.

4. Epoch Locking: The N seeders selected attempt to "lock" the epoch by signing the xor of all N seeds, including their own. In the event of an inoperable or unresponsive seeder, the remaining seeders should have a mechanism to collectively exclude them and proceed with the epoch locking.

Protocol Enhancements and Resilience Mechanisms:

1. Inoperable Seeder Handling: A significant piece of work remains in developing a protocol to manage inoperable or unresponsive seeders. The protocol should include safeguards to prevent misuse and ensure the system doesn't halt if a seeder fails to complete their part of the locking process.

2. Network Latency Management: While the Locutus network has low latency, we need to ensure the system can effectively handle time-sensitive operations like seed collection and epoch locking, even in the face of possible network fluctuations.

3. Long Term Locking of Seeders: Develop a mechanism to lock in seeders over the long term to prevent retroactive regeneration of valid old random numbers. This might involve using cryptographic commitments, where seeders commit to their seeds ahead of time in a manner that doesn't reveal the seed but can be revealed and verified later.

4. Short-term Validity of Random Numbers: The protocol should clearly specify that the generated random numbers are only valid for short-term use. This is a measure to prevent an adversary with significant computational resources from confusing the system by recreating an old random number.

Further Work:

1. Formalize the protocol and conduct a rigorous analysis of its security, robustness, and fairness properties.
2. Perform comprehensive testing and simulations to identify potential vulnerabilities and mitigation strategies.
3. Design and implement the collective exclusion mechanism for unresponsive seeders, ensuring it is resilient to misuse.
4. Develop the long-term seeder locking mechanism to prevent retroactive regeneration of old random numbers.
5. Set clear expectations for the validity period of the generated random numbers to prevent misuse.

This PVRNG proposal aims to provide a robust starting point for community engagement and discussion. Additional refinements, suggestions, and improvements are welcome as we strive to build a secure and truly decentralized RNG for the Locutus network.

[ple1n]

It can be biased. Do they commit to the seeds ?

[sanity]

Not sure what you mean, can you elaborate?