-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Baseline #18
Baseline #18
Conversation
Use of the draft networking library
Merge with the restructure_mains branch to update the .gitignore which will ignore the “deploy/platform/localhost/*"
|
It is already present in the .gitignore. (?) |
Then delete the files from git... I think the .gitignore got updated AFTER the files were added. About the |
RIght sorry didn't catch up those files >< |
Awesome, thanks - and sorry I haven't been able to keep up with stuff while I'm in the thick of this conference. Have you been able to run an experiment with this code comparable to the others, and if so, Linus, can you add the resulting dataset to the graphs you plotted for me? (Sorry if it's already in my inbox and I just haven't gotten to it yet! ;) ) |
The experiment is being run, but not yet at 8192 nodes... |
Finally putting in the big rework - some more to come, but still
Just to include the offline-discussion in this By this I meant that it uses the same communication pattern as the Cothority scheme - i.e., nodes in the (same) tree communicate only with their immediate parent and children - but instead of true collective signing, the nodes just aggregate individual signatures going up the tree. To be more specific, this protocol could probably just operate in a single “round-trip” over the tree rather than the two round-trips that the Cothority needs: (1) the leader announces the message to be signed, and it propagates downward through the tree to the leaves as a straight multicast message; then (2) each leaf produces a conventional, individual signature on the message with its public key and sends its signature up to its parent node, and intermediate nodes simply concatenate these signatures together into lists (and add their own individual signatures) going up the tree; and (3) finally the root simply receives a long list of individual signatures from all the nodes that were present in the tree; this whole list is now the “naive” collective signature, which anyone may check simply by checking all the individual signatures. Like I said it’s not necessarily essential to have this, but if it’s easy to hack together quickly as a variant, it would be helpful because it would allow us to separate and measure precisely the performance benefit we get from (a) using the efficient communication tree, and (b) using the multisignature crypto magic. These are logically separate and orthogonal optimizations that we implement (either could be implemented without the other), and it’s just good practice in experimental research to try to separate orthogonal improvements or optimizations like these and give the reader of a paper a sense for which are more or less important in the big picture, etc. |
Closing - continue in #30 |
* Fix in creating connection based on TOML format * Fix in getSkipblock method. * Data interfaces for further API modification
This is the branch where I develop the other baseline such as the naive baseline where one leader ask the signature of all others servers (and check all of them).