polygon-edge: Error: failed sending StakeManager contract deploy transaction: failed to get max priority fee per gas: {"code":-32601,"message":"Method not found"}
Error on polygon-edge polybft stake-manager-deploy
Description
I’m trying to deploy the stake manager contract on my Layer 1 (Besu) with the command polygon-edge polybft stake-manager-deploy
but I’m getting the following error:
Error: failed sending StakeManager contract deploy transaction: failed to get max priority fee per gas: {"code":-32601,"message":"Method not found"}
Full command:
polygon-edge polybft stake-manager-deploy \
--private-key "${L1_ACCOUNT_PK}" \
--genesis ${OUT_FOLDER}/genesis.json \
--jsonrpc ${RPC_URL} \
--stake-token ${STAKE_TOKEN_ADDRESS} \
--proxy-contracts-admin ${L2_ACCOUNT_ADDRESS} \
--json
Can this be related to the new tx pool implementation on Besu? Ref: https://github.com/hyperledger/besu/releases/tag/23.10.0
EDIT:
Tested it on different Besu versions, one with new and another with legacy tx pool. Same error.
Your environment
- MacOs
- polygon-edge 1.3.1
- besu 23.10.0
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Comments: 18 (8 by maintainers)
Nope, those are two different concepts. Chain ID is an arbitrary number, that uniquely identifies a given chain and its semantics as for Ethereum, to prevent replay attacks. On the other hand, the supernet ID is a unique identifier of the given Supernets chain. It is auto-generated on the
StakeManager
contract whenever a Supernets gets registered (https://github.com/0xPolygon/core-contracts/blob/7393eef151150177fb3bec8101071a0e87a19f19/contracts/root/staking/StakeManagerChildData.sol#L24-L31), because some time ago it was envisioned that we have a single instance onStakeManager
and multiple Supernets chains, which gets registered on the sameStakeManager
(however still we are not enforcing such architecture, apparently, it seems that we are about to have a separateStakeManager
per Supernet).Yes, it gets autoincremented each time a new Supernet chain is registered in the
StakeManager
contract (done with therootchain deploy
command). It is used to uniquely identify Supernet when doing stake, unstake etc., because as I’ve written previously, it is supported that a singleStakeManager
serves multiple Supernets.This error message often indicates that execution got reverted on the smart contract. Stake transaction can fail because of several reasons:
Can you verify that the contract address provided for the
--stake-token
flag exists on the rootchain?I don’t think so, because in that case (if an account with 0 balance is executing
eth_estimateGas
), the given error would be much more like this:If you don’t figure it out yourself, then please provide the exact commands you are running as well as the
genesis.json
and ideally debug logs of the Supernets (you can omit private keys of the accounts that are executing given commands, but it would be potentially helpful if you can provide their addresses).@refl3ction awesome glad it worked. Thanks for your feedback. 🙂
@Stefan-Ethernal I left a suggestion for your consideration on the PR, I think the arguments are inverted in the
strings.Contains
function. I fixed it locally and it worked 🎉As per this question, checkpoint submission is also affected with this change (aside from
stake-manager-deploy
,rootchain deploy
,stake
etc. commands which are interacting with a rootchain)@refl3ction Although the PR is still in draft and not merged into the
develop
(because there might be some additional minor tweaks, in terms of expanding that list), you should be able to test it out. Hope it will work for you. 🙏Btw I’m not sure when we are going to make another release, but PR should be merged in the following days hopefully.
@refl3ction you are absolutelly right about it: all the bootstrapping commands that are run against the rootchain are sending dynamic fee transactions and are fallbacking to legacy only in case
ErrTxTypeNotSupported
is retrieved. I was about to propose you to run Foundry and manually deploy all the required contracts, however I agree it is tedious and error prone work.So I agree with you that we probably can add another error which would fallback to legacy tx sending. It should be an easy win. In fact right now there is a pending task on which colleague is working so I’ll let him know about this issue.
@Stefan-Ethernal I assume the same will occur after I run any command that needs to interact with the L1, like
polygon-edge rootchain deploy
,polygon-edge polybft whitelist-validators
,polygon-edge polybft register-validator
,polygon-edge polybft stake
?Does it make sense to check for
Method Not Found
errors here? Because this is what would be returned by Besu in this case, and it’s just checking against the following error:ErrTxTypeNotSupported = errors.New("transaction type not supported")
Initially, I was thinking that one way to work around this, for now, would be to translate this function and all the others that call the
eth_maxPriorityFeePerGas
to some shell instructions and do all of the RPC calls using Foundry. But if my assumption is correct, it would be a lot of work and maybe it would be easier to support the case whereeth_maxPriorityFeePerGas
is not supported or wait for Besu to support it. Thoughts?