Was there no way to just make PARSEC faster?
The procure is exactly as described in my post. Only at the last step I try to create an account (after all 7 vaults were created).
For each vault I waited for the right routing table size to appear, plus some margin until no messages are exchanged anymore.
2 Likes
So you are facing the same issue when creating fresh accounts as well?
If that’s the case then it’s definitely a bug. Because once a section is setup, the client will declare an account successfully created only if it receives a success response from all the vaults.
Edit: The client only looks at the last response.
But on the other hand, if a 3 vaults return success and 4 return failure, then the client will return a failure but the account’s existence is inconsistent between vaults in the section and this is indeed a known limitation of the current testnet.
1 Like
Yes, anytime I tried to create a new account. This was last Sunday. But now I have restarted a new network directly with 7 vaults which doesn’t exhibit this problem. And I don’t want to lose this configuration so I cannot make new tests.
You can see from the logs that the client always received one success response and 6 error responses.
If the success response was the last to be received then the command was successful.
If an error response was the last then the command failed.
Good to know!
Ah yes. Sorry my bad. The client just looks at the last response. I’ll edit my message 
Would you like a fix to be implemented for this?
Client says Success if only all vaults return success? This might bring up some other inconsistencies but it’s definitely an improvement.
1 Like
Ok, client only looking at the last response explains the second problem.
Once again what about the first problem? It shouldn’t have happened according to your remark:
In fact I would like more a fix for this one because if it is corrected in the first place, then the second problem won’t occur.
It may well be possible. But it seems if we don’t need to have strict order on some things then we can lighten the load of what we do need to parsec for (which should speed things up).
6 Likes
Agreed, good idea. Just spitballing here, but have you looked into whether the strict ordering in PARSEC could be relaxed ( as an option depending on use case)?
For example rather than saying ‘this sequence of individual events happened in order’ it would be ‘this sequence of event sets happened in order’.
An ‘event set’ would just be a bag/group of unique unordered events. Perhaps the move to larger and larger blockchain block size is a good analogy?
2 Likes
