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
As part of the shanghai code in erigon there is a check for initcode being over a certain size if shanghai is enabled, this is true in normalcy networks, but the implementation in cdk-erigon checks just call data rather than checking call data AND if the transaction is a create or not.
erigon upstream has already altered the code to stop this from happening in version 2.60.8 which should be our basis for fixing this issue:
The text was updated successfully, but these errors were encountered:
Hey @hexoscott in cdk-erigon the function validateTx
if isShanghai && txn.Creation && txn.DataLen > fixedgas.MaxInitCodeSize {
return txpoolcfg.InitCodeTooLarge // EIP-3860
}
Checks if the transaction is a contract creation (txn.Creation), and only applies the limit on the init code size if that’s the case. This means that the code is correctly filtering out regular transactions and only focusing on contract creation ones when it comes to checking the size.
So, it’s already ensuring that the init code size limit is applied correctly – only to contract creation transactions, not regular ones.
Hi @MKVEERENDRA - thank you for the feedback. During development of cdk-erigon we ported the pool.go file over from erigon-lib to the zk folder in the codebase so that we could make pool changes there. During the merge of upstream erigon to version 2.60 the erigon-lib directory was pulled locally, but we continue to use the pool.go file in the zk folder which doesn't have these additional checks around the transaction being a create so we need to update that.
As part of the shanghai code in erigon there is a check for initcode being over a certain size if shanghai is enabled, this is true in normalcy networks, but the implementation in cdk-erigon checks just call data rather than checking call data AND if the transaction is a create or not.
erigon upstream has already altered the code to stop this from happening in version 2.60.8 which should be our basis for fixing this issue:
The text was updated successfully, but these errors were encountered: