Open drewstone opened 9 months ago
@drewstone could you please say more on the LeaderElection
option here? I'm working on this in #419 and I did not understand what a LeaderElection
would do?
Yea so for trusted setups we will actually need to select the next contributor for the trusted setup ceremony. We can call this process leader election in the sense that a leader needs to be chosen to do the task, one at a time, as is done in a consensus process like AURA. We can have a variety of leader election processes, namely
So to add to this, we can have leader election over a fixed party set (or over no fixed set) and we likely want to be specific about what type of leader election it is, so we can support many in the future. Imagine you want to have these participants run a sequencer for an L2, or a random number generator process, and we want to use stake to weight their ability to contribute. All things should be considered here in this spec/task.
https://a16zcrypto.com/posts/article/leader-election-from-randomness-beacons-and-other-strategies/
Overview
We want a way to support roles where any valid worker can participate. This is necessary for the light client relaying, trusted setups, and other one-shot tasks or MPCs. For example, I should be able to create a job for anyone that possesses the
LightClientRelaying
role and as such anyone with that role can submit jobs. For trusted setups, we may want to have the same logic supported albeit that requires a bit more work in deciding who does the job (this could be handled by custom pallet logic).Empty vec
One way we can handle this is by using an empty participants vec for jobs where we want anyone to participate. Then it becomes the responsibility of some custom logic to either identify who should be submitting jobs when (for trusted setup for example which requires leader election) or free for all (for the light client and other relaying tasks).
Enums
We could turn the participants item into an enum that can be configured for different settings, such as