protocol / research

Research at Protocol Labs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Secret Single-Leader Election

miyazono opened this issue · comments

Single Secret Leader Election

The Filecoin block reward is a large term in the incentive equation, and is wielded as such to align the incentives of participants. As a result, we developed Expected Consensus to ensure that miners are elected in a fair, secret, and publicly verifiable manner. See Section 6 of the Filecoin paper for motivation and formal definitions (namely, Definition 6.1).

However, the number of miners elected in Expected Consensus follows a distribution centered at 1. (If all miners have the same power, the distribution is binomial.) As a result, the Filecoin Protocol must be robust against the election of multiple miners or no miners in any given epoch.

To simplify this, we seek a solution that provides the aforementioned properties of Fairness, Secrecy, and Public Verifiability while electing exactly one miner at each epoch.

Ideally, this could be achieved without substantial modifications or additional complexity added to the Filecoin Protocol itself.

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) modulo 2$ 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.