Number of active members is limited to 255 #1107
Conversation
|
maximum_number_of_members@7752 aka 20200429.6 vs master ewma over 50 builds from 7329 to 7749 |
| @@ -318,6 +319,7 @@ TEST_CASE("simple bank") | |||
| Store::Tx gen_tx; | |||
| GenesisGenerator gen(network, gen_tx); | |||
| gen.init_values(); | |||
| gen.create_service({}); | |||
There was a problem hiding this comment.
Can that be rolled into init_values()?
There was a problem hiding this comment.
We should do that. However, the whole GenesisGenerator class needs splitting and I didn't want to start combining some functions before doing that. Ideally, there will eventually be a init_service(cert) that initialises the state of the service.
| throw std::logic_error("Failed to get active service"); | ||
| } | ||
|
|
||
| // If the service is opening, members are added as ACTIVE |
There was a problem hiding this comment.
Is that right? Do we then reset their status after opening?
It wouldn't be correct for a member to be added who has neither voted on opening nor acked to be counted as active.
There was a problem hiding this comment.
That's a very good point. We don't reset their status after opening the service indeed.
I see two options:
- All members are added as
ACCEPTEDandACCEPTEDmembers can propose/vote when the service is opening. The members who vote for the service to open automatically becomeACTIVEwhen the service is open - other members stayACCEPTED. - All members are added as
ACTIVEwhen the service is opening. When the service is opening, the members who haven't voted for the proposal are reverted toACCEPTED.
There was a problem hiding this comment.
I am starting to wonder if a single value is a good way to capture this.
Members can:
- Have endorsed the ledger up to a point (vote in opening, ack)
- Vote
- Count towards a vote count
- Use their keyshare to execute a recovery
There was a problem hiding this comment.
Having read the relevant parts of the TR and thought about this a bit, I don't think the service status should have a bearing on this.
ACCEPTED - Ack (no exceptions) -> ACTIVE - Removal proposal passes -> RETIRED
This should be the state machine at all times. Members can never be automatically ACTIVE, because it would wrongly imply their participation, and it would count towards quorum, potentially stalling votes. That's true all the same when OPENING.
So I suggest a third option, which is that members have to Ack before they can vote/be counted.
If we want to avoid unnecessary acking, I think the right solution is to allow ACCEPTED members to always vote, and count the first vote as an ack. This is problematic though, for them to vote, they must be counted, and counting identities that never have shown activity or signed a single thing with their private key seems overly optimistic.
There was a problem hiding this comment.
@jumaffre as discussed, let's stick with the TR approach for now, which has the merit of being simple to explain and to implement. Only ACTIVE members can vote. Members become ACTIVE on first ack.
Resolves #851
Following #51, the number of active members at any given time should be <= 255 (limitation of the underlying secret sharing library). We believe this is OK for now (until we decide that not all members should be handed a recovery share, see #1021).
CCF will now return a meaningful error message if the number of active members > 255 (either if the service is
OPENINGwhen a member is added or when the service isOPENand a member transitions fromACCEPTEDtoACTIVE).