I remember hearing about this and will need to dive in more but here's a thought. Why not run a tournament-style modulo reduction on pairs of miners by their public keys until there is a winner, if we run into the case of multiple leaders.

Say you have some set $S=(1,2,...,n)$ of chosen miners. You pair them up and compute $add(publickey1,publicKey2)modulo2$ and select the participant's index, recursing on the updated set for the next "round".

I don't think you can assume a fixed number of miners n in blockchain network.

@alishoker I don't mean that it is fixed, but you do know (or can, i.e. from the PoS literature) at each round the set of "validators" or storage "miners". $n$ is a random variable for the sake of argument.

Sure. But the requirement of this task is "electing exactly one miner at each epoch" which can't be guaranteed if one of the elected validators go offline—this is not uncommon in such networks. PoW solves it by having several validators running in parallel.

That said, one can opt to live with a protocol that guarantees "at least one" validator as it is currently done in many protocols; and then have a random, but deterministic, arbitration method to elect one out of them.

This "random, but deterministic, arbitration method to elect one out of them" can be your suggestion.

@drewstone, I'm intrigued to hear more of this idea of combining keys to make sure you only get one, particularly how you would achieve fairness with this scheme. I think this also doesn't give a secret election, but I imagine you might be able to find a way by indexing a list of sorted public key signatures. I'm happy to discuss potential ideas here.

It's also worth noting, though, that if you'd like to write up a proposal, we have an RFP on this problem and are interested in funding directions that look promising.

New SSLE RFP out and accepting proposals.

I'm coming from outside the field. How does this naive procedure fail?

• At each round, each potential miner generates a public/private keypair and publishes the public key.
• SSLE procedure uses the assumed randomness source and stake weights to select a miner; sends it the message, "you win"; sends other miners the message, "you lose".
• Winning miner publishes next block along with its private key.
• Other miners verify that this private key decrypts the winning message.

Hi @clumma,
Since Filecoin is a fully decentralized algorithm, there is no trusted entity to run the SSLE procedure and message the miners. The SSLE procedure has to be run independently by every miner, so in the naive procedure, any miner could run the SSLE procedure for other miners in abstentia to determine the winner, which results in security issues. Feel free to read the problem statement above or linked here for more information.

Thanks @miyazono for your reply. I did read the problem statement but didn't catch where it explains the setting for running the SSLE -- probably it's expected readers just know this.

A set of solutions (of which one practical) has been written on this paper: https://eprint.iacr.org/2020/025.pdf

Thanks for the link, @nicola! For a little bit of self-promotion, here's the corresponding PL Research link:
https://research.protocol.ai/research/publications/single-secret-leader-election/

Hi all, thank you for your comments! 🚀 We are now closing the issue, feel free to reopen it in the future if you want to restart the conversation on this topic.