Skip to content
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

Ensure that the state of a concurrent transaction is repeatable. #3

Open
hypercube-lab opened this issue Sep 8, 2021 · 1 comment
Labels
0.1 good first issue Good for newcomers question Further information is requested
Milestone

Comments

@hypercube-lab
Copy link
Owner

At the moment, there is nothing that prevents a validator from accepting two batches of transactions and processing them in parallel mode. It's conceivable that the debits from the second batch will cause an account to overdraw before the credits from the first batch are credited to the account. If this were to happen, the validator would erroneously vote a legal block as an invalid block, which would have no effect on anyone's account, but would result in a needless rollback and the leader's bond being slashed without justification.

Due to the fact that transactions spanning tick borders are guaranteed to be sequentially consistent, we will most likely only need to submit a Tick to the historian immediately after processing the parallel batch of transactions.

@hypercube-lab hypercube-lab added this to the Testnet milestone Sep 8, 2021
@hypercube-lab hypercube-lab added good first issue Good for newcomers question Further information is requested labels Sep 9, 2021
@agnitazudkll
Copy link
Contributor

this would require further research

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.1 good first issue Good for newcomers question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants