-
Notifications
You must be signed in to change notification settings - Fork 20.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core, light, params: implement eip2028 #19931
Changes from 1 commit
acad147
80bb52c
1b34f35
4c7d373
d94d5dd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -217,6 +217,9 @@ type TxPool struct { | |
signer types.Signer | ||
mu sync.RWMutex | ||
|
||
homestead bool // Fork indicator whether we are in the homestead stage. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wouldn't include homestead here. Strictly speaking this code is more correct, because if someone runs a Frontier chain, the pool will act weirdly. That said, I don't think we can afford to maintain all the quirks of all past forks indefinitely. The EVM must have the quirks of course because it's consensus, but we don't expect anyone to run a frontier txpool, so lets just not complicate things. |
||
istanbul bool // Fork indicator whether we are in the istanbul stage. | ||
|
||
currentState *state.StateDB // Current state in the blockchain head | ||
pendingNonces *txNoncer // Pending state tracking virtual nonces | ||
currentMaxGas uint64 // Current gas limit for transaction caps | ||
|
@@ -540,7 +543,7 @@ func (pool *TxPool) validateTx(tx *types.Transaction, local bool) error { | |
return ErrInsufficientFunds | ||
} | ||
// Ensure the transaction has more gas than the basic tx fee. | ||
intrGas, err := IntrinsicGas(tx.Data(), tx.To() == nil, true) | ||
intrGas, err := IntrinsicGas(tx.Data(), tx.To() == nil, pool.homestead, pool.istanbul) | ||
if err != nil { | ||
return err | ||
} | ||
|
@@ -1118,6 +1121,15 @@ func (pool *TxPool) reset(oldHead, newHead *types.Header) { | |
log.Debug("Reinjecting stale transactions", "count", len(reinject)) | ||
senderCacher.recover(pool.signer, reinject) | ||
pool.addTxsLocked(reinject, false) | ||
|
||
// Update all fork indicators by next pending block number. | ||
next := new(big.Int).Add(newHead.Number, big.NewInt(1)) | ||
pool.istanbul = pool.chainconfig.IsIstanbul(next) | ||
if pool.istanbul { | ||
pool.homestead = true | ||
} else { | ||
pool.homestead = pool.chainconfig.IsHomestead(next) | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If the dynasty is changed, should we recheck all pending txs which we receive by old consensus rules? Probably no, A corner case is: we reach the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, no need to recheck past ones. We only care that the intrinsic gas is lower than the total requested gas when inserting into the pool. As we're pushing the gas down, it will always hold true when transitioning into Istanbul. If we have a reorg back from Istanbul into Homestead that might be a bit messy indeed, since we might accept some transactions that would become invalid, but I don't think this is a legit issue we need to concern ourselves with. At worse the pool might be shuffling junk until the chain progresses again into Istanbul. |
||
} | ||
|
||
// promoteExecutables moves transactions that have become processable from the | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really nasty to pass a batch of fork indicators. What about using a
dynasty
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could pass the ChainConfig perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or the
chainRules
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but we use this function in some tests, so it seems weird to construct the
chainRule
, maybe worse thanhomestead, istanbul
. So what's your prefer?ChainRules
can make normal path code nicer, but test is a bit dirtyThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I agree we can have flags. But actually, I'd personally prefer to have not
istanbull bool
but insteadeip2028Active bool
(and possiblyeip155Active bool
).