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
❗ to be done after actual off-chain tx execution is introduced
Some key points:
Tx pool must not accept any "add transaction" requests, unless fully synced.
If node is not fully synced, new transactions must not be accepted, as their processing will result in state inconsistency. Also the problem is related to recent block hashes window - if node is in a sync state, it must be kept in mind that the window state is invalid.
When syncing blocks txs propagation is performed by networking layer, so done independantly from the syncing process. It would easier to validate received by network txs and reproduce block commitments (which will include offchain transactions), if tx is gossiped along with recent blockhashes window. This data can be used to store newest txs until newest blocks aren't reached (synced)
Solution must test the case that when node is syncing, sending originally old transaction (but with a reference block hash valid against the lagged block hashes window) is denied.
The text was updated successfully, but these errors were encountered:
❗ to be done after actual off-chain tx execution is introduced
Some key points:
If node is not fully synced, new transactions must not be accepted, as their processing will result in state inconsistency. Also the problem is related to recent block hashes window - if node is in a sync state, it must be kept in mind that the window state is invalid.
Solution must test the case that when node is syncing, sending originally old transaction (but with a reference block hash valid against the lagged block hashes window) is denied.
The text was updated successfully, but these errors were encountered: