Discussion topic for RFC 59
I’m for option 1:
Advantages: less modifications to PARSEC required.
Disadvantages: need to pass messages from Adults via Elders, need to expose the DKG from PARSEC to Routing or to duplicate its functionality in Routing.
It seems to be implied by the drawbacks mentioned for option 2, that it would be an easier path of the two. And so, in the spirit of focusing on reaching an MVP…
As the ‘old adage’ (well, hrrm) goes:
- Make it work.
- Make the code/solution more maintainable.
- Make it fast.
One more thing: introducing logic in PARSEC that is specific to the implementing context made me apprehensive. Going down that direction risks decreasing its usefulness in other contexts.
Anyway, by going with either the resulting behaviour should not be affected, so moving over to option 2 (or some other option) at a later time would still be possible it seems to me.
Naturally I’m not fully familiar with the context and all the implications with the two options, or what more they entail, but that’s what it looked like to me when reading the RFC.
The above is a change relative to the pre-BLS behaviour. Before, we required more than 2/3 of the section to sign a message before it was valid. t = f means that more than 1/3 of the section will be enough after implementing BLS.
I don’t know what the cost per signature difference is between pre- and post-BLS, but if it is small then this seems to be a big efficiency gain. (And the evolution btw a perfect example of ‘the old adage’).
sig checks are not too high and not the bottleneck AFAIK. BLS aggregate sigs are slower than ED and can be by a factor. There are ways to alter that, but basically it is the conciseness of a group key that makes this neat for me. The fact the key you have from the old group is instantly useless in the new group. In EC we overlap this and use the same key from starting to going off line and it has the same authority in eahc “set” of group authority keys. tl;dr an aggrigate sig of 3 nodes may be slower than sig check of 5 nodes in ED, but overall it is probably faster to check the validity of the sig set with BLS, it that makes sense?
Yep absolutely, makes sense. I think the consiceness of a group key is splendid.
I actually assumed that BLS would be slower (was about to edit and insert ‘[diff] … smaller in favour of pre-BLS’, since I noticed that it was implicit assumption), and so that was my thinking: if not much slower, then this could be a big efficiency gain.
I was thinking about the whole process when saying ‘signature cost’, so total cost . Like, if you have N = 10 nodes running an operation end to end with pre- and post-BLS, measuring the time, counting number of sigs required for each, we would have total cost per sig (maybe it’s not linear, but an expected normal count of Elders wrt section size limits could be used for N).
I was thinking that even if the pre/post diff is bigger, it would seem to be partly compensated by the fewer sigs required.
And then, as you mention, additional effects from faster checking of validity.
And so all these factors would be included if doing the above test.
Not terribly important to do now if you already can tell it’s good enough by other means, but this was my thinking of what was included when referring to ‘cost per signature’ - so the total cost.
It is not necessarily the case that option 2 is more work. My intuition is that it is likely a smaller amount of work than option 1.
The reason is Option 2 has most of its DKG work in Parsec code base (so it is changes Parsec more), while option 1 has to re-implement things outside of Parsec code (so the Parsec code may change a bit less, but at the expense of all the code around Parsec that need to change significantly more).
Final Comment Period
The BLS RFC will remain open for the next 10 days to allow any final comments to be made.
Thank you for contributing!