Committee Size: number of members or credits?

[fed-franz]

Currently, committees have a maximum 'size', which is actually the number of 'voting credits' distributed among committee members.

However, there are some inconsistencies in the code as well as in the design due to the misinterpretation of 'size' as number of members in the committee.

For instance, the committee size is decided based on the number of available provisioners: if these are less then the maximum committee size (currently, 64), than size is set to the number of provisioners. This is coherent with size as number of members, but not much with the credits version.
Now, assuming we stick to size as credits, and we remove the above behavior, when would 'size' be lower than the maximum, and why? I think we're missing some rationale behind this. What does 'size' actually represents?

I think this requires more discussion to decide what is the behavior we want and why.

@herr-seppia @goshawk-3

Related Issues:
#1519
#1520

[goshawk-3]

From an implementation standpoint, it is more practical to have a fixed number of credits/slots. This approach is simpler to implement, maintain, and comprehend.
As for performance, we shouldn't anticipate any adverse consequences since we expect to have more than 64 provisioners in the actual (mainnet/testnet) network.

@fed-franz

[fed-franz]

I think it's critical to define what size actually represents in the sortition/consensus process.
Do you know why is it currently set to 64?

[herr-seppia]

64 is used to fit the bitset of voting provisioners into a 64bit long

Actually should be 63 (since 0 is noone voted yet)

[fed-franz]

After discussing it, we agreed that:

• committee size is the number of credits
• 64 is somewhat arbitrary, and simply represents "enough" voting credits to be distributed among eligible provisioners
• this number is independent from the number of provisioners in the network