-
Notifications
You must be signed in to change notification settings - Fork 20
Description
Currently, a single centralized aggregator node collects keyshares/decryption shares, generates aggregation proofs (C5/C7), and submits results on-chain. It holds the contract owner's private key, isn't bonded or slashable, and is a single point of failure, if it goes offline, every E3 fails.
For each E3, designate the first N - M committee members (by party_id from the finalized topNodes ordering) as aggregators. This requires no new node type or a config parameter as the aggregator count is derived from the existing threshold.
party_id 0becomes the primary aggregatorparty_id 1= first fallback (submits after a timeout if nothing on-chain yet)- ...up to
party_id N-M-1
All nodes run the same binary. Aggregation logic activates conditionally per-E3 based on committee position.
This would allow us to remove the onlyOwner from publishCommittee() since we now have C5 ZK proof verification
We considered selecting aggregators from a separate set of nodes that don't participate in DKG #1278, but after much thought and research, we can achieve the same results by choosing the aggregators from the e3 committee itself.
The first option also has a large implementation cost as it needs a second sortition round, new contract state, new slash policies, new reward pool, new P2P routing (separate aggregators aren't committee members so gossip won't reach them)
Also, committee members have proven they're online by completing DKG; separate aggregators have proven nothing beyond registering