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
When utilizing the Scroll network for computationally intensive tasks, there's a risk of hitting processor limits within the ZK processors, potentially leading to transactions becoming stagnant or "zombie" in the transaction pool. While the Scroll team is aware of and working on solutions to this issue, proposed solutions may not be immediately implementable. Existing mechanisms, such as substitution based on pending nonces, still require gas consumption and a certain level of user awareness, which may not be ideal for all use cases.
To enhance the system's efficiency and user experience, it would be beneficial to introduce an additional transaction purge system tied to the transaction pool's lifetime. This system would automatically remove "zombie" transactions that exceed a certain age threshold, ensuring a more dynamic and clean transaction pool.
Proposed Implementation
The idea revolves around periodically checking the age of transactions in the pending transaction pool and removing those that exceed a predefined lifetime. The proposed Go code snippet outlines a basic approach to this:
// Handle lifetime check for pending transactionscase<-pendingLifetime.C:
pool.mu.Lock()
foraddr, list:=rangepool.pending {
// Skip local transactions from the eviction mechanismifpool.locals.contains(addr) {
continue
}
// Evict non-local transactions that are beyond their lifetimefor_, tx:=rangelist.Flatten() {
iftime.Since(tx.Time()) >pool.config.Lifetime { // Assuming tx.Time() exposes transaction timestamppool.removeTx(tx.Hash(), false) // Remove transaction from the pool
}
}
}
pool.mu.Unlock()
This implementation leverages a timer to periodically trigger checks against the transaction pool.
Each transaction's timestamp (assumed to be exposed via tx.Time()) is compared against the current time to determine if it exceeds the pool's configured lifetime. Transactions meeting this criterion are then removed from the pool.
so my understanding is
previously we only checked if time.Since(pool.beats[addr]) > pool.config.Lifetime
you suggest we check all the txs (except the local ones), and can probably use a dedicated pendingLifetime.C instead of evict.C for it.
but if a tx is send thru an PRC node,
then by default it will be treated as "local" by the RPC node, and will not be removed,
then your codes still cannot achieve the goal, correct?
(unless he send thru an RPC but query from another RPC)
Rationale
When utilizing the Scroll network for computationally intensive tasks, there's a risk of hitting processor limits within the ZK processors, potentially leading to transactions becoming stagnant or "zombie" in the transaction pool. While the Scroll team is aware of and working on solutions to this issue, proposed solutions may not be immediately implementable. Existing mechanisms, such as substitution based on pending nonces, still require gas consumption and a certain level of user awareness, which may not be ideal for all use cases.
To enhance the system's efficiency and user experience, it would be beneficial to introduce an additional transaction purge system tied to the transaction pool's lifetime. This system would automatically remove "zombie" transactions that exceed a certain age threshold, ensuring a more dynamic and clean transaction pool.
Proposed Implementation
The idea revolves around periodically checking the age of transactions in the pending transaction pool and removing those that exceed a predefined lifetime. The proposed Go code snippet outlines a basic approach to this:
This implementation leverages a timer to periodically trigger checks against the transaction pool.
Each transaction's timestamp (assumed to be exposed via tx.Time()) is compared against the current time to determine if it exceeds the pool's configured lifetime. Transactions meeting this criterion are then removed from the pool.
Related to #498
The text was updated successfully, but these errors were encountered: