From 56422c87e9d7edeab9aa99e7d37cb00a8994a67f Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Tue, 11 Feb 2025 13:55:22 +0100 Subject: [PATCH] core/txpool/legacypool: update comment --- core/txpool/legacypool/legacypool.go | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/core/txpool/legacypool/legacypool.go b/core/txpool/legacypool/legacypool.go index 4637cf7628..c7ff954a49 100644 --- a/core/txpool/legacypool/legacypool.go +++ b/core/txpool/legacypool/legacypool.go @@ -198,18 +198,19 @@ func (config *Config) sanitize() Config { // current state) and future transactions. Transactions move between those // two states over time as they are received and processed. // -// In addition to tracking transactions, the pool will also track pending set -// code authorizations. This helps minimize number of transactions that can be -// trivially churned in the pool. As a standard rule, any account with a -// deployed delegation or an in-flight authorization to deploy a delegation will -// only be allowed a single transaction slot instead of the standard number. -// This is due to the possibility of the account being sweeped by an unrelated -// account. Because SetCode transactions can have many authorizations included, -// we avoid explicitly checking their validity to save the state lookup. So long -// as the encompassing transaction is valid, the authorization will be accepted -// and tracked by the pool. In case the pool is tracking a pending / queued -// transaction from a specific account, it will reject new transactions with -// delegations from that account with standard in-flight transactions. +// In addition to tracking transactions, the pool also tracks a set of pending SetCode +// authorizations (EIP7702). This helps minimize number of transactions that can be +// trivially churned in the pool. As a standard rule, any account with a deployed +// delegation or an in-flight authorization to deploy a delegation will only be allowed a +// single transaction slot instead of the standard number. This is due to the possibility +// of the account being sweeped by an unrelated account. +// +// Because SetCode transactions can have many authorizations included, we avoid explicitly +// checking their validity to save the state lookup. So long as the encompassing +// transaction is valid, the authorization will be accepted and tracked by the pool. In +// case the pool is tracking a pending / queued transaction from a specific account, it +// will reject new transactions with delegations from that account with standard in-flight +// transactions. type LegacyPool struct { config Config chainconfig *params.ChainConfig