limit delegator's tx count in tx pool

[libotony]

No description provided.

[ifavo]

@libotony May I ask what triggered this change?

And why is there a limit for 16 transactions per delegator paid tx/account in the pool?
I imagine an attacker could easily setup plenty of accounts dynamically to get around the limit?

Cheers,
Mario

[libotony]

@ifavo, the transaction pool operates on a decentralized basis, thus there is a limitation to its size. To prevent the dominance of a single address over the majority of transactions in the pool, we have implemented an account level limit, creating a unique queue for each account. We’ve discovered that this kind of limit should be imposed on a delegator as well.

While these measures are not intended as a definitive solution for potential DoS attacks, they add a layer of complexity that may deter such malicious activities. Given the assertion that ‘attackers could easily set up plenty of accounts’, it is important to remember that there are costs involved. For an attacker to monopolize the network’s bandwidth, each transaction fee must be paid, thereby making the undertaking costly.

As for the queue size, it stands at 16, which is a parameter we could adjust. Currently, we have adopted this value from Ethereum’s implementation.

[ifavo]

@libotony thank you for taking time to explain! I understand.

Do I understand correctly that this prevents more than 16 transactions sponsored by the same delegator in a single block?

I believe this is relevant, because high throughput dApps might become throttled on a peak, if they use fee delegation and more than 16 users are active at the same time.

[libotony]

@libotony thank you for taking time to explain! I understand.

Do I understand correctly that this prevents more than 16 transactions sponsored by the same delegator in a single block?

I believe this is relevant, because high throughput dApps might become throttled on a peak, if they use fee delegation and more than 16 users are active at the same time.

You’re correct. We advise user-agents, such as wallets in web-based applications or server apps in a backend-based application, to establish a local transaction queue. This is essential because the decentralized transaction pool may unpredictably reject or drop a transaction when it reaches its capacity.

For high-throughput decentralized applications and those that are time-sensitive, we highly recommend the use of multi-clause transactions.

We apologize for any inconvenience the modifications to vechain.energy may have caused. We acknowledge that these might have a negative effect on your applications; however, these changes were imperative for security enhancement. Please feel free to reach out to any of us if you have any concerns.

[ifavo]

For single applications that can control the transaction flow a queue or multi-claused transactions are easily to implement.

I was thinking more of a NFT Minting event where many users are going to mint simultaneously and more than 16 users could be actively participating at the same time. Fee Delegation creates a problem that situation. I will watch out for such situations, if this theoretical situations happens. Scaling to different delegation wallets or delaying transactions could be a simple solution.

It opens an attack vector to delegators as well I believe, that needs to be managed, if a malicious user spams a dApp delegator with more than 16 transactions per 10s. Thats not drastic, just needs to be noted.