wighawag / hardhat-deploy

hardhat deployment plugin
MIT License
1.2k stars 296 forks source link

Deployment failed - "invalid sender" (Ubuntu 20x64, Geth 1.10.7-stable) #177

Open safead opened 3 years ago

safead commented 3 years ago

Can not deploy any contract to private network with Geth version "1.10.7-stable". Ways to reproduce:

Setup private ethereum node, start with:

geth --nousb --datadir="/root/.ethereum/" --mine --allow-insecure-unlock --unlock "0x957F8A0Ee6D80D9a3b9459eD5Eb3996d7D5d4982" --rpc --rpcport 59321 --rpcaddr "GETH_SERVER_IP" --rpccorsdomain "*" --rpcapi "admin,eth,miner,net,txpool,personal,web3"

Take any contract, for example I took "Owner.sol" from http://remix.ethereum.org/. Does not matter which contract to use.

hardhat.config.js:

module.exports = {
  solidity: '0.8.4',
  namedAccounts: {
    deployer: 0,
    tokenOwner: 0,
  },
  networks: {
    1515: {
      chainId: 1515,
      url: 'http://GETH_SERVER_IP:59321',
      accounts: ['0xafbb26819a2279c4f9d8f96ffb2936123643f9f6ef620566aa3499c82bed9e2e'],
    },
  },
};

deploy.js:

const hre = require("hardhat");

async function main() {
  const { deployments, getNamedAccounts, getChainId } = hre;
  const chainId = await getChainId();
  const { deploy } = deployments;
  const { deployer } = await getNamedAccounts();
  console.log({ chainId, deployer });
  const result = await deploy('Owner', {
    from: deployer,
    log: true,
  });
  console.log({ result });
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

run:

npx hardhat run scripts/deploy.js --network 1515

I'm always get this error:

invalid sender {"name":"ProviderError","code":-32000,"_isProviderError":true} ProviderError: invalid sender

If I downgrade the geth to version 1.9.10 all works fine, I'm stuck here for a week, please assist what I'm doing wrong.

wighawag commented 3 years ago

Hey sorry for the latre reply, but could it be that the --unlock behave differently than before in geth and the eth_getAccounts do not expose it anymore ?