-
Notifications
You must be signed in to change notification settings - Fork 7
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
Robustness: concurrency issues #345
Comments
it might in fact be quite difficult for the authentication server (AS) to handle that case! What I think happens is:
So the AS would have to store the counter in its database and increase it for every TX it sends. |
@ineiti nope, you're missing the proxy that does the "transaction manager". |
Who is handling the nonce? The proxy? |
Can you elaborate the Also copying form slack: Pierluca Borsò-Tan: I think we might be able to store a counter on the proxy side, but we can also probably tune the parameter defining how far ahead the nonces are allowed. I can’t recall the exact name, but there’s a parameter that indicates how “early” a nonce can show up (i.e., nonces are monotonically increasing, and if we’re at nonce 10, do we tolerate 13, 15, 17 yet or not?) |
Answering my question about whether nonce 11 is refused or not: looking at the logs Carine posted above, it seems that yes, it is refused once nonce 12 is accepted. So we definitely want to add a counter in the authentication server to take care of this problem. Btw: I think |
The transaction is created here and the associated nonce is managed in the same place: That function is called by the transaction manager in the D-Voting proxy |
In my opinion you should not make the authentication server responsible for managing the nonce:
For me this should be solved at the GUI level. Every action that implies a transaction on the blockchain must be assumed to be a promise that can be resolved or rejected, and the GUI should clearly display that. When an error occurs (for example the transaction didn't get included because of the nonce) the user should be notified and have the opportunity to retry. Most of the work is about having a better error handling + feedback provided to the users (typically when I cast a ballot, I should have a confirmation that the transaction has been included, or an error explaining what happened and the opportunity to re-cast my vote) |
Some thoughts:
So I'm still convinced that handling the nonce at the AS level is the way to go. Of course it is not ideal to have one more job for the AS. But I'm trying to have something working for the end of the month. The ideal way would be of course that the AS only does the authentication, and the GUI does all the rest. Unfortunately this doesn't seem to be possible without rewriting big parts of the d-voting project. But if we're re-writing that much, we'd have to consider using the old e-voting, which has a lot of functionality needed already built-in and is well stress-tested. How did this work for the demo for Unicore? You didn't go above 256 blocks, and nobody voted concurrently? |
Changed the way nonces are handled in the proxy where the transactions are signed. Now we can have transactions with increasing nonces in blocks. In 2024/03 we get about 8 transactions/block. |
When transactions come in too fast to DELA, they seem to get invalid nonces:
which leads to them just getting "ignored" i.e. votes are not taken into account, nodes are not getting initialised, ...
The text was updated successfully, but these errors were encountered: