forks/go-ethereum
1
0
Fork 1
mirror of https://github.com/ethereum/go-ethereum.git synced 2026-08-17 09:23:48 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

core/txpool/legacypool: update comment

Browse source
This commit is contained in:
Felix Lange 2025-02-11 13:55:22 +01:00
parent 37247f9461
commit 56422c87e9
1 changed files with 13 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
core/txpool/legacypool/legacypool.go
View file

@ -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