You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Explain how race-conditions might affect programs.
A discussion popped up within the core Entropy team recently (paraphrased):
It doesn't matter how much time passes. When a user like Alice asks for a signature, there is a delay (D) between asking for the signature and putting it on the chain.
For example, if Alice requests a transaction with nonce = 1, but during the time delta, Bob also requests a transaction, he checks the chain and also sees a nonce of 1. So, he creates the transaction. After time D, we end up with two transactions both having nonce 1. Then, when Alice submits the nonce as now = 2, all transactions with nonce 1 become invalid. Similarly, when Bob submits his transaction, it's also invalid. In essence, it becomes a competition between anyone requesting a transaction within the time delta D.
User-developers should be aware of race-conditions like this, and should design their programs around them. Let's give user-developers some pointers on how they can mitigate situations like this.
The text was updated successfully, but these errors were encountered:
Explain how race-conditions might affect programs.
A discussion popped up within the core Entropy team recently (paraphrased):
User-developers should be aware of race-conditions like this, and should design their programs around them. Let's give user-developers some pointers on how they can mitigate situations like this.
The text was updated successfully, but these errors were encountered: