keep-ecdsa
keep-ecdsa copied to clipboard
keep-network
Signer selection scheme
Include selection scheme candidates for a ticket-based scheme and an optimized 16-ary tree sortition pool scheme
There is another important aspect here that is not necessarily in the scope of this PR but may help us to choose the solution: what happens if the selected members become idle and do not generate the threshold key?
I think it's a little easier to handle for the ticket-based solution: we timeout key generation and start group selection again. We can use the same assumption as for the beacon: the fact group members burned ether on group selection is enough for punishment.
It's probably a little more complex for the lazy eligibility evaluation: operator could request to participate in a pool when the gas price was very low. At the moment of creating a keep and generating a key, the gas price can be much higher. Don't we need additional KEEP token slashing here?
Instead of KEEP token slashing, I'd look into seizing a bit of the bonds of inactive operators; the ETH can then be used to pay for selecting new candidates while KEEP would need to be sold somehow to gain operating currency.
And in any case, there is also the opportunity cost of not getting the rewards of performing work. The ability of a single member to force DKG abort doesn't lend itself to control bootstrapping unless someone already controls >33% of all stake, so there isn't necessarily a reason to penalize failed DKGs beyond the opportunity cost.
I went through both propositions again and honestly, it's clear to me that if we want to be testnet-ready by the end of the year and mainnet-ready for Q1, we should go with the ticket-based approach. If we find it not sufficient long-term we can always update this approach in V2. What do you think @eth-r?
Couple of quick tests here:
- Agree on ticket-based approach.
- Checking in with Matt, it seems in an ideal scenario we'd be able to form multiple groups off of one beacon entry, given how long a beacon entry can take to come in an ideal world where deposit throughput would be higher than beacon + ECDSA keep member selection (even if this latter part were instant). Interested in thoughts on whether we can use a ticketing approach and treat the results in a queue-like fashion. Wondering if we end up with the worst of both worlds here, but… It'd be nice if that weren't the case 😅
